On Jul 4 12:46, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with "rm -rf" of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files were presumably still "in use". Repeating
the command several times would succeed, though.
Downgrading from cygwin1.dll/1.7.9.1 to cygwin1.dll/1.7.8.1
seems to have solved that issue as well - still have to see
the first "retry to delete".
This may or may not be related to the original report, as it also reeks
of a race condition during file/directory operations.
I can neither reproduce the tar problem, nor can I reprocude the rm
problem. I tried this under 2008R2 which is basically the same as your
W7-64 bit. I used local and remote drives to test the issue but to no
avail.
Finally I managed to reproduce the problem and now I see what happens.
Windows does not write back the file change timestamp unless the file
buffers are flushed. This usually occurs at close time. In contrast to
POSIX specifications the timestamps are *not* automatically updated when
a call to fetch file metadata is performed.
Here's what tar does when creating the symlink:
1. create file with 000 permissions
2. fstat
3. close file
[...]
4. stat file
5. if fstat.st_ctime != stat.st_ctime ==> symlink placeholder has been
overwritten.
The problem is that the call to fstat on the opened handle gets some
value of the change time timestamp, but the subsequent close changes
the timestamp again.