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

[The Wanderer]

(quoting reordered for my sanity's sake)

On 12/17/2005 02:43 AM, Jim Meyering wrote:

> Mikko Rasa <address@hidden> wrote:
>
> > Package: coreutils
> > Version: 5.93-5
> > Followup-For: Bug #340236
> >
> > I hit this problem as well today. Poking around with strace, I
> > noticed several things:
> >
> > 1. cp executes utimes before closing the file. This might be a
> > problem, although it seems to work on local destinations.
> >
> > open("baz", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4
> > fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> > write(4, "foo\n", 4)                    = 4
> > utimes("/proc/self/fd/4", {1134767841, 0}) = 0
> > chmod("baz", 0100644)                   = 0
> > close(4)                                = 0
> >
> > 2. Timestamps of empty files are preserved, which reinforces the
> > above suspicion (no writes for empty file)
> >
> > 3. touch -r works correctly, and it also uses /proc/self/fd to
> > refer to the file, so that should be okay.
> >
> > address@hidden:20 23:17:56 ~/roinaa/test$ echo "foo" >foo
> > address@hidden:20 23:18:29 ~/roinaa/test$ strace -e utimes touch -r foo bar
> > utimes("/proc/self/fd/0", {1134767841, 0}) = 0
> > address@hidden:20 23:18:34 ~/roinaa/test$ strace -e utimes cp -p foo baz
> > utimes("/proc/self/fd/4", {1134767841, 0}) = 0
> > address@hidden:20 23:18:37 ~/roinaa/test$ ls -l --full-time
> > total 8
> > -rw-r--r-- 1 tdb tdb 0 2005-12-16 23:18:29.000000000 +0200 bar
> > -rw-r--r-- 1 tdb tdb 4 2005-12-16 23:18:37.000000000 +0200 baz
> > -rw-r--r-- 1 tdb tdb 4 2005-12-16 23:18:29.000000000 +0200 foo
>
> Thanks for the report.
> You might be right that the problem is due to the combination of
> using /proc/self/fd/N and NFS.
> I've Cc'd bug-coreutils, in case someone else has time to investigate
> this.

Hmm. I've encountered a potentially similar problem, which may or may
not be related. It appears, now that I look at it a little more closely,
to have a few different aspects. (For the record, this is likewise with
5.93.)

I copied a directory hierarchy across a network to a shellfs mount,
using --preserve=all. All of the files on my local machine were owned by
me, all had 664 permissions, and none had been modified since 2003. As a
control (if you want to call it that), copying from one drive to another
on my local machine preserved all of these characteristics.

When they arrived at the far end, all of the ones whose filenames
included a single-quote character returned the "preserving timestamps:
Operation not permitted" error, and all of those proved upon examination
to now have 644 permissions. (The original files were, of course,
unmodified.)

What's more, every file which had been copied now proved to have also
had its timestamp updated - even though only 56 out of the 206 had
produced the "Operation not permitted" message. Interestingly, this
applied only to files; the directories in the hierarchy had their
timestamps preserved perfectly.

In a later test with a single file, mv also produced the same effect, at
least in terms of timestamps being updated. I have made a few sporadic
tests beyond that, but none which have produced any new information.

If there's anything I can do to help resolve this, given an almost
complete lack of previous experience with programming on such levels,
please feel free to ask.

--
      The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.