GNU bug report logs - #9277
cp

Previous Next

Full log

View this message in rfc822 format

From: Eric Blake <eblake <at> redhat.com>
To: vesselin kavalov <vesselin_kavalov <at> yahoo.com>, 9277 <at> debbugs.gnu.org
Subject: 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

Previous Next

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