[Top][All Lists]
[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
- bug#9277: cp, vesselin kavalov, 2011/08/10
- bug#9277: cp, Eric Blake, 2011/08/10
- Message not available
- bug#9277: cp,
Eric Blake <=
- Message not available
- bug#9277: cp, Eric Blake, 2011/08/10