> >
> >
> > Could this "Strangeness" be due to file virtualisation?
> >
> > You mention that you are moving (have moved?) from Win XP to Win 8.1, in between those versions Microsoft introduced file visualisation to protect special folders (two special folders are anything in the \Windows area and anything in the \Program Files or \Program Files (x86) folders).
> >
> > This can lead to issues where your code is seeing something but when you go look on the hard drive you might be seeing something different, causing the confusion.
> >
> > An example would be that you have some code which is going to put a file in a folder in a "protected path" or edit the file or delete the file, lets just say something like:
> >
> > C:\Program Files (x86)\Company Name\Application Name\config.mem
> >
> > In modern versions of Windows the file doesn't get put in that path because Windows protects the path from meddling, it instead goes into a virtualisation path within your local user data but processes can "see" the file as if it is at C:\Program Files (x86)\Company Name\Application Name\config.mem even though it isn't actually there.
> >
> > This is one of the biggest headaches coders faced when they moved from Windows XP to Windows Vista or above, if they hadn't already steered away from working with Program Files and Windows folders. Before MS forced this virtualisation feature into Windows Vista they had recommended staying away from those folders as best practices but plenty of coders didn't know about those best practices until they tried to get their application working in Windows Vista. Ten years ago I was working at a company where all our application were installed in \Program Files\Company Name\ and even the data was as well, we had to solve that when Vista could be previewed and we found that there were incredibly strange things happening in our application around data and files.
> >
> > If you are not dealing with any of the special paths then this is not likely to be the cause of your strangeness but if you are I'd say you might need to consider working in non-protected paths if you want an easier life in newer versions of Windows.
>
> Thanks! No, I resolved the "don't mess with Program Files" issue a while back when Vista first came out. But Fernando Bozzo's comment makes me wonder if it doesn't have something to do with putting folders in the root of a drive under later versions of Windows. When I copied the development folders, I put them in the locations equivalent to where they were on the XP system, thinking to minimize the variables that might be in play as I tested how it worked under the newer OS.
>
> Although the application itself is not dependent on a specific path, some of the development utilities I wrote have hard-coded paths that I have been working to eliminate, so if I move the folders, I'll need to complete that. I started out using #DEFINEs for this, but I'm wondering if it would be better to set public variables for development oriented paths to avoid the need to recompile utilities if the development folder ever gets moved again.
As Fernando has clarified there does not appear to be any problem with using a sub-folder of the root of the c: drive. The root of c: is one of those protected folder, I think we can all agree on that and we've all known that for a long time but I don't know of any version of Windows which would have a problem using a sub-folder of c:\ as long as that folder is not one of the other protected folders (i.e. c:\windows or c:\program files).
For years (decades even) I've worked with folders like c:\temp\ and our software when installed locally by default is installed at c:\auction and we have no problems in any version of Windows. A number of people even recommend avoiding the default installation area for VFP (c:\program files (x86)\Microsoft Visual FoxPro) and instead install to an area like c:\VFP, for the same reasons of file virtualisation and permissions around the Program Files (x86) folder. Personally I don't go that far, I don't have the same problems those people describe in any versions of Windows, including 10, 8.1, 8 & 7 so I am happy using that installation area (probably because I don't edit any files in that path - to my knowledge - so that's why it doesn't cause me any problems).
Maybe you've had a standalone permissions problem, in other words a permission problem due to something other than the standard Windows issues around UAC and File Virtualisation. Certainly if you are working in a folder like c:\MyApp\ then I wouldn't expect any of the build in permissions issues, we certainly don't suffer them.