bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9277: cp


From: Eric Blake
Subject: bug#9277: cp
Date: Wed, 10 Aug 2011 15:43:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.11

[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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]