Eric Blake redhat.com> writes:
...
>
>
> No, because they don't use ctime the way that cygwin1.dll uses ctime.
> They probably have other hacks in their port of tar to work around lack
> of POSIX features that cygwin1.dll is emulating.
Do you mean that the implementation of ctime in cygwin1.dll
Here is a patch to tar that fixes the problem by using mtime instead of ctime.
Yes, it's not a problem with cygwin or tar, but I see no way for users to
figure out, under Windows, which processes are changing the status of their
files.
diff -ur tar-1.25-copy/src/extract.c tar-1.25/src/extract.c
--
Christopher Faylor cygwin.com> writes:
> Cygwin doesn't change the creation time gratuitously. Sounds like BLODA
> to me.
> http://cygwin.com/acronyms/#BLODA
>
> cgf
Good call! I killed Vid.exe from Logitech and reduced the probability of
failure from 25% per file to 1%. Sadly, killing oth
Thanks for the correction. That's what tar looks at.
Corinna Vinschen cygwin.com> writes:
> Btw., POSIX st_ctime is not "creation time" but "change time".
>
> Corinna
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
(Re-posting yet again, didn't get through yesterday or today (?), this time
from a different account.)
Corinna,
Debugging with gdb shows that "tar" is prepared for the possibility that
symbolic links don't work and that hard links will have to be used instead.
So, when it encounters a symbolic l
5 matches
Mail list logo
