Mail Archives: cygwin/2005/10/19/10:33:32
Angelo Graziosi <Angelo.Graziosi <at> roma1.infn.it> writes:
> 1)
> Using coreutils-5.90-3 I have observed that the command 'cp -p' does not
> preserve the timestamp of a file:
>
> $ ls -lrt
> -rw-r--r-- 1 Administrator Administrators 418 Aug 7 18:55 t.c
>
> $ cp -p t.c t.cpp
> $ ls -lrt
> -rw-r--r-- 1 Administrator Administrators 418 Aug 7 18:55 t.c
> -rw-r--r-- 1 Administrator Administrators 418 Oct 18 19:05 t.cpp
>
> Reinstalling coreutilis-5.3.0-9 the files have the same timestamps.
As far as I can tell, this is a bug in cygwin.
5.3.0 made the following sequence of calls:
dest_desc = open(dest,...);
write(dest_desc,...);
close(dest_desc);
utimes(dest,...);
chmod(dest,...);
5.90 makes the following sequence of calls:
dest_desc = open(dest,...);
write(dest_desc,...);
utimes(dest,...); // at this point, timestamp is correct
fchmod(dest_desc,...);
close(dest_desc); // oops, timestamp changed
I can't see anything in SUSv3 that lets close() change the mtime of an open
file descriptor that has not been modified since the last utimes() to the same
underlying file.
Meanwhile, coreutils does check for futimes, and would use that if cygwin were
to provide it. That might help, since the problem stems from the fact that the
utimes() to an open file is being lost on close(), but an futimes() would only
work on an open file.
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -