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

[The Wanderer]

On 12/22/2005 01:18 AM, Paul Eggert wrote:

> The Wanderer <address@hidden> writes in
> <http://lists.gnu.org/archive/html/bug-coreutils/2005-12/msg00199.html>:
>
> > I copied a directory hierarchy across a network to a shellfs mount,
>
> What's a shellfs mount?  Sorry, I've never heard of shellfs.

It's essentially the ability to mount as a filesystem any directory you
can access via ssh (or similar), implemented as a kernel module.

http://shfs.sourceforge.net/

I find it vastly more convenient than NFS, at least on our local
network, and far less limited (mainly in terms of legal filenames and so
forth) than Samba. It's a bit slow to respond sometimes, but there are
tradeoffs in everything. It's useful enough, and has been around long
enough, that I'd assumed it would be widely known... shows what you get
for assuming, I guess. <grin>

> > 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,...  What's more, every
> > file which had been copied now proved to have also had its
> > timestamp updated.
>
> That sounds very much like an error in the shellfs implementation; it
> shouldn't matter at all whether the file names contain a
> single-quote character.  You can verify this by using "strace"
> (GNU/Linux) or "truss" (Solaris) on the cp -p command.  Something
> like this:
>
> strace -o foo.tr cp -p source dest
>
> and then look at foo.tr to see what utimes and/or futimes did.

Yeah, I know the presence or absence of the single-quote shouldn't make
a difference - and for all I know it doesn't; it's just that that's the
only commonality I could see between the files which did produce the
error vs. the ones which didn't (I've seen variants of this behaviour
before, some of them IIRC actually on my local machine rather than
across a network, and could never figure out the common element before).

The strace output does not refer to utimes by name. The relevant EPERM
is returned by something referred to as SYS_271 - presumably the label
simply means "strace could not identify the name of this syscall" - and
all five of the arguments are given only as hex values. Since utimes
takes only two arguments, I don't think that's what this is. Any idea
how to figure out what call is being made?

For comparison, a 'successful' cp across the same connection (one which
does not produce that message, but still updates the timestamps) has
SYS_271 return 0 but gets EOPNOTSUPP from both getxattr and setxattr on
the destination file.

A quick test of a local (cross-filesystem but not cross-machine) cp of
the second file, which does not update the timestamps, shows exactly the
same error - the only difference between the local log and the shfs one
is that the latter does not contain a fchown32 call. The fact that there
is no visible difference, other than the paths involved, between the log
of the local cp (which does not update the timestamps) and the log of
the remote one (which does) seems like it should probably mean that shfs
is silently failing to behave as expected.

(For full parallelism: all of the differences between the strace logs of
a remote cp which produces the error message and a local
cross-filesystem cp of the same file seem to cascade from the fact that
in the remote case the initial SYS_271 call fails.)

> > If there's anything I can do to help resolve this,
>
> If the problem is limited to shellfs (whatever that is), then I'd
> file a bug report with the shellfs maintainers, giving a test case
> that will let them reproduce the bug.  It sounds like they have at
> least two bugs, one involving file name quoting and the other
> involving time stamps.

At a glance at the strace results, now that I have some clue about what
to look for, it does look like a shfs problem - albeit not for quite the
reason you mentioned. I probably wouldn't have figured that out if I
hadn't been trying to get enough information to convince you that it was
not the case, so thanks for the kick in the pants.

--
      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.