bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#340236: coreutils: cp -p to nfs destination fails to preserve ti


From: Paul Eggert
Subject: Re: Bug#340236: coreutils: cp -p to nfs destination fails to preserve timestamps
Date: Wed, 21 Dec 2005 23:05:39 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Mikko Rasa <address@hidden> writes:

> 1. cp executes utimes before closing the file.  This might be a problem,
> although it seems to work on local destinations.

I don't observe the problem on my Debian host, when running coreutils
5.93 (which I compiled).  This is with Linux kernel 2.4.18-686, libc
2.3.2, as an NFS client with a Solaris 8 NFS server.  So possibly it
is a bug in your NFS server, or (more likely) in some change to the
kernel that occurred after 2.4.18.  Here is the relevant strace output
on my host:

write(4, "================================"..., 3813) = 3813
utimes("/proc/self/fd/4", {1135233674, 0}) = -1 ENOSYS (Function not implemented
)
utime("/proc/self/fd/4", [2005/12/21-22:41:14, 2005/12/21-13:23:28]) = 0
fchmod(4, 0100664)                      = 0
close(4)                                = 0

One thing jumps out as being different for me.  On my host, utimes()
returns -1 with errno==ENOSYS, and utime() works.  On your host,
utimes() returns 0, but the time stamp is botched.


I just verified that coreutils 5.93 does work with an OpenBSD 3.4 NFS
client and a Solaris 8 NFS server.  OpenBSD has an futimes system
call, which works correctly.  So the problem is not inherent to NFS
and futimes; futimes can be implemented correctly over NFS.


This problem reminds me of the "utimes() vs. close()" thread
<http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00206.html>,
in which "cp -p"'s more-aggressive use of utimes ran afoul of a bug in
Cygwin.  I asked the POSIX folks about this (see
<http://www.opengroup.org/austin/mailarchives/ag-review/msg01971.html>)
and the answer came back that the Cygwin behavior was indeed a bug;
see <http://www.opengroup.org/austin/mailarchives/ag/msg08912.html>
and look for "XBD ERN 61".  The problem reported here for Linux
2.6.14.2-s2.2-rc11 and NFS looks similar.


Perhaps the bug should get refiled under the nfs-common package?  It
does seem to be a misbehaving implementation of futimes(), which is
not just a coreutils issue.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]