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

[The Wanderer]

On 12/22/2005 12:48 PM, Brian Dessent wrote:

> The Wanderer wrote:
>
> > 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?
>
> It looks like on x86 linux, 271 is in fact utimes(), according to
> <http://www.lxhp.in-berlin.de/lhpsysc0.html>.

Not a place I even knew existed, much less could have guessed to look...

> The fact that strace shows 5 arguments is probably because it cannot
> identify it (and thus does not know the nature of its arguments), not
> because it actually has 5.

I presumed that that was the reason for the arguments being displayed as 
hex values, but where would the

> It is a bit odd that your strace does not
> identify this -- are you sure you're using a strace that was compiled
> against the proper kernel headers? It sounds like you're using an old
> strace with a newer kernel.

No, I'm not sure about that - despite recent "upgrade or remove" package
clean-up efforts, I was running a version of strace which was at the
very least not the most recent available. (I've never compiled it
myself, which would seem to be the only way to be sure that the kernel
headers involved are the correct ones - although then there's the whole
"which kernel headers should be installed?" issue to contend with...)
I've upgraded, and running the test again confirms that SYS_271 is in
fact utimes().

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