GNU bug report logs - #9277
cp

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9277 in the body.
You can then email your comments to 9277 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: vesselin kavalov <vesselin_kavalov <at> yahoo.com>
To: bug-coreutils <at> gnu.org
Subject: cp
Date: Wed, 10 Aug 2011 11:40:26 -0700 (PDT)

[Message part 1 (text/plain, inline)]

cp -a src/{a,b,c} dest does NOT preserve the time stamp on symbolic links.

I understand that neither does 'tar' , but that probably is a fault, not a 
feature there either.


Thanx!
vess

[Message part 2 (text/html, inline)]

Message #10 received at 9277-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: vesselin kavalov <vesselin_kavalov <at> yahoo.com>
Cc: 9277-done <at> debbugs.gnu.org
Subject: Re: bug#9277: cp
Date: Wed, 10 Aug 2011 13:09:52 -0600

On 08/10/2011 12:40 PM, vesselin kavalov wrote:
> cp -a src/{a,b,c} dest does NOT preserve the time stamp on symbolic links.

Thanks for the report, but you are missing some details.  What version 
of coreutils?  What operating system?  And assuming Linux, what kernel 
version?

Be aware that symlink timestamp preservation requires the use of 
futimens or utimensat, which were only recently standardized by POSIX 
2008, and which are lacking on a lot of older systems; plus, being new 
interfaces, they require newer coreutils that actually takes advantage 
of the newer interfaces.  Also be aware that symlink timestamps are 
worthless - there's generally not much you can usefully do with them, 
whether or not you have the flexibility of modifying them.

At any rate, things work for me, using kernel 2.6.35 and coreutils 8.5 
(the defaults of Fedora 14):

$ ln -s a b
$ sleep 20
$ cp -a b c
$ stat b c
  File: `b' -> `a'
  Size: 1         	Blocks: 0          IO Block: 4096   symbolic link
Device: fd02h/64770d	Inode: 266785      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (14986/  eblake)   Gid: (14986/  eblake)
Access: 2011-08-10 13:04:42.420640012 -0600
Modify: 2011-08-10 13:04:34.308611690 -0600
Change: 2011-08-10 13:04:34.308611690 -0600
  File: `c' -> `a'
  Size: 1         	Blocks: 0          IO Block: 4096   symbolic link
Device: fd02h/64770d	Inode: 304795      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (14986/  eblake)   Gid: (14986/  eblake)
Access: 2011-08-10 13:04:59.771700484 -0600
Modify: 2011-08-10 13:04:34.308611690 -0600
Change: 2011-08-10 13:04:57.174691438 -0600

Note that atime and mtime were indeed preserved.  Therefore, I'm closing 
this bug unless you can provide more details about any bugs still remaining.

>
> I understand that neither does 'tar' , but that probably is a fault, not a
> feature there either.

Wrong again.  The latest tar, coupled with the latest kernel, does 
support symlink timestamps.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Message #13 received at 9277 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: vesselin kavalov <vesselin_kavalov <at> yahoo.com>, 9277 <at> debbugs.gnu.org
Subject: Re: bug#9277: cp
Date: Wed, 10 Aug 2011 15:43:20 -0600

[re-adding the list]

On 08/10/2011 03:14 PM, vesselin kavalov wrote:
> Hi Eric, I am NOT an OS or kernel expert - just a Joe-user out there - so put up
> with my rather limited understanding of the matters.
>
> The example that you show here actually confirm my initial contention, I
> believe. Let's look at the time stamps as the time progresses:
>
>
> 1. ln -s a b
>        b ->   Modify: 2011-08-10 13:04:34.308611690 -0600
>              Change: 2011-08-10 13:04:34.308611690 -0600
>              (I don't understand why Access: is ~ 8 sec later ???)

Every time you readlink() a symlink, that updates the atime (and stat(1) 
is using readlink() to tell you what the symlink contains).  You're 
better off seeing if mtime was stable, since although atime can be 
adjusted backwards in time by newer kernels, it won't stay there for 
long if you make any decent use of the symlink.

>              Change: 2011-08-10 13:04:57.174691438 -0600<- 23 seconds later 'c'
> got created (as with regular 'cp')
>
>
>
> What 'ls -l' shows I believe IS the change time and thus is shows WHEN the 'cp
> -a ...' took place NOT a copy of the original 'b' stats

The ctime is always the timestamp of the last change to the file 
metadata; that is the last time the symlink was created, or the last 
time it was altered by utimensat.  You cannot make ctime go backwards, 
so it cannot ever be an identical copy.  Only atime and mtime can be set 
arbitrarily.

> And yes, I do have a use for the link's timestamp ->  I am 'releasing' bunch of
> files, directories and links from a working area to a release area
> and want to preserve timestamps AS THEY HAPPENED, and later in a release area if
> a link timestamp changes - I know that somebody monkied
> with the files and THIS might have broken the release.

atime means they merely read the symlink; you should only be worrying 
about mtime (if you trust them to not use utimensat to fake mtime) or 
ctime (which cannot be faked).  But since ctime cannot be copied, the 
best you can do using timestamps is mtime and hope for a sane user.

> I am NOT even a SW guy - I do CAD automation, so if you know of a better way of
> releasing and having a proof of authenticity of the released area - I will be
> humbled to learn something new and better.

Rather than going off of timestamps, why not go off of content?  That 
is, it seems like your real concern is whether the files have changed 
content, not whether they have had timestamps changed.  Decent version 
control systems do just that (such as git).  Even checksumming utilities 
are a reasonable way to gain assurances that content is correct.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Message #16 received at 9277 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: vesselin kavalov <vesselin_kavalov <at> yahoo.com>, 9277 <at> debbugs.gnu.org
Subject: Re: bug#9277: cp
Date: Wed, 10 Aug 2011 16:14:27 -0600

[re-adding the list again - there's a reason that we prefer public lists]

On 08/10/2011 04:07 PM, vesselin kavalov wrote:
> Hi Eric,
> yes, I can do SHA, but on the real file contents only! That's why I hate soft
> links! because everything may stay the same, but a change of where a soft link
> points to is undetectable and U get different results of subsequent compiles. I
> probably will go brute force and set restrictive unix permissions on a different
> user and group ownership.

You can do SHA on symlink contents, by using readlink on those symlinks. 
 Your claim that symlink changes are undetectable is bogus.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.