MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
gcc version 4.7.0 (GCC)
Windows 7 Enterprise SP1
I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view. When trying to copy a view private file, the 'cp' command would fail with a message like
skipping file `jj', as it was replaced while being copied
The problem is that the 'cp' command uses 'stat' on the source file initially, and then, when it's ready to copy, uses 'fstat' on it again, after the file has been opened for reading (about line 237 in copy.c from coreutils-5.97). This works on a file that's on a local hard drive, but not on a Clearcase locally hosted dynamic view. The 'install' command has the same problem.
This test really shouldn't be done on a Windows platform. Microsoft's documentation describes different values for stat.st_dev returned by the 'stat()' and 'fstat()' functions. There's also a note that the stat.st_ino value is meaningless for NTFS filesystems.
But then it gets interesting. The 'cp' command is built with a different version of 'stat' and 'fstat' than one normally gets with a MinGW build environment. The coreutils need the Msys build environment, and the 'stat/fstat' functions are pulled from libmsys-1.0.dll.a. A build in regular MinGW environment with the current compiler gets the functions from libmoldname.a. So were the coreutils built with gcc-4.7.0, and no libmsys-1.0.dll.a, the copy command would fail for files on the local hard drive, since stat.st_dev is different for stat() and fstat().
I've attached a small test program to show the stat()/fstat() output, and a patch for system.h in coreutils that allows a working version of 'cp.exe' and 'install.exe' to be built.