Case-sensitive file rename does not work

189 Views Asked by At

The following program does not work when compiled with Visual Studio 2010 on Windows 7:

#include <stdio.h>

int main()
{
    int status;

    status = rename("C:\\Temp\\A.dat","C:\\Temp\\a.dat");
    status = rename("C:\\ProgramData\\A.dat","C:\\ProgramData\\a.dat");

    return 0;
}

The first rename works, but the second rename does not work. The rename function returns 0 in both cases. What is so special about c:\ProgramData that keeps the case sensitive rename from working?

Just FYI, the program works fine when compiled with cygwin gcc 4.8.3.

1

There are 1 best solutions below

5
Vineet1982 On

C:\ProgramData has has security settings that prevent standard user from writing there. This is not new in Windows 8, Windows 7 was the same, and the equivalent folder on Vista is also secured in this way. Perhaps your Windows 7 environment of UAC has not disabled, or perhaps you have secured C:\ProgramData or C:\ProgramData\MyProgramName to permit write access to standard user.

Somethings you must something about UAC

When Microsoft introduced UAC they needed a way for older applications to continue working, at least for a while. What they came up with was "File and Registry virtualization", where legacy applications that tried to access (now-)verboten System folders or registry entries would be redirected to their own user-specific "virtualized" copy of those resources. As the Wikipedia article on UAC.

To put it straight, ProgramData contains application data that is not user specific. This data which will be available to all users on the computer.

There are a couple of approaches to the use of this folder. Some applications write there only during installation whilst the installer process is running elevated. Then the application itself, which runs as standard user, can read, but never attempts to write.

Another approach is for the installer to create a sub folder of C:\ProgramData that is secured to allow write access for standard user, or whatever user/group that you the developer deem appropriate.

If your program "Run as administrator" privileges then you should be able to avoid this issue.