2

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.

mstrsn
  • 21
  • 3
  • Probably, authority of writing is not. check `c:\ProgramData` property --> security tab --> `Users`(or other). also use the Administration console. – BLUEPIXY Apr 21 '15 at 15:33
  • You could try to use MoveFile() instead and check GetLastError() to pinpoint the error. – AndersK Apr 21 '15 at 16:12
  • Why do you expect this to behave one way or the other? Neither C documentation nor Windows documentation say what exactly should happen in this case. – n. m. could be an AI Apr 21 '15 at 17:34
  • I cannot reproduces this (using a non-admin account). – alk Apr 21 '15 at 17:49

1 Answers1

1

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.

Vineet1982
  • 7,730
  • 4
  • 32
  • 67
  • 1
    This does not explain the difference in behaviour between two compilers. – n. m. could be an AI Apr 21 '15 at 17:16
  • Shouldn't `rename()` indicate an error (and probably set `errno`) in case of insufficient access rights? (https://msdn.microsoft.com/en-us/library/zw5t957f%28v=vs.100%29.aspx) – alk Apr 21 '15 at 17:39
  • @alk Each of these functions returns 0 if it is successful. On an error, the function returns a nonzero value and sets errno to one of the following values: EACCES; ENOENT; EINVAL – Vineet1982 Apr 21 '15 at 17:54
  • @n.m. As this problem is not about compilers. As through windows compilers run through winows libraries but in cygwin i.e like unix doesn't depend on windows libraries – Vineet1982 Apr 21 '15 at 17:57
  • As Vineet1982 suggested, "Run as administrator" did avoid the issue. But if I change the program to rename the file to a different name (not just a case change), then it works. So it seems the problem is more about changing filename case than about permissions. – mstrsn Apr 21 '15 at 22:05