Red Hat Bugzilla – Bug 230866
cp -Pp does not preserve the timestamp of the source
Last modified: 2010-10-22 09:00:55 EDT
Description of problem:
cp --no-dereference --preserve=all or cp -Pp
preserves alright the attributes of a file, but not those of
a symlink. The copy of the symlink gets timestamped with the
Version-Release number of selected component (if applicable):
bash version 3.2 Release 9.fc5.1, but the cp used does not seem
to be a bash builtin. Not sure what package includes cp.
Steps to Reproduce:
1. create a tests directory, cd tests
cat > file1
contents of file 1
ln -s file1 symlink1
.... wait 2 minutes here ....
cp -Pp file1 file1c
cp -Pp symlink1 symlink1c
2. observe that the date/time of file1 and file1c are identical,
while those of symlink1 symlink1c are not.
different timestamps in source and target symlinks
same timestamp in source and target symlinks
This is intentional:
/* There's no need to preserve timestamps or permissions. */
preserve_metadata = false;
(from copy.c, if (S_ISLNK (src_mode)))
Jim, should the documentation be updated to reflect this, or should timestamps
be preserved on symlinks?
On most systems, it is not possible to preserve timestamps on symlinks. None of
the syscalls that do that for other file types can be applied to symlinks; if
you try, they operate on the pointed-to file, not the symlink. utimes works
this way. Same holds for permissions. This is so basic, I'm not sure coreutils
is the right place to document it, but if you want to add a sentence to
coreutils.texi, I'll be happy to apply it upstream, too.
Alright, let's leave it as it is.
This is between funny and sad. Not sure.
Can someone in the discussion enlighten me about how is that an exception
to a general semantics (preserve-metadata in this case) does not need to
be justified, and instead, the question asked is "should the documentation
be updated to reflect this?". That is not even a question, assuming that
the exception was explained and justified, which was not, if there is an
exception, it needs to be documented without a question. Kinda "period".
That is what we, software professionals do. We did this for the 40 years
that I am in this business and I found nowhere, other than in the comments
to this bug report, any hint about the absolescense of this all-important
usability rule. But the core of the question remains: how in heck is that
this is NOT A BUG?. If you buy a green Honda Accord 2007, and get an Honda
Accord 2007 that is yellow: it runs, it performs the same way, etc. but it
DOESN'T LOOK the same way -> only and single conclusion is that THIS IS NOT
THE CAR YOU BOUGHT even though it functions in all aspects that YOU ARE
ABLE TO DETECT like the one you bought. However, you missed a point: the
green car fits well in the green background of your front yard. The yellow
does not. This is quite the same: the (normal human user) perception of the
parameter "preserve metadata" is that the metadata of all objects copied is
preserved. Usability and respect to the human user dictates that this should
be so for all objects, INCLUDING SYMLINKS, as their metadata is VISIBLE when
I do "ls -l". Hi-tech explanations of what
functions are not affected by the (still unjustified, arbitrary) exception,
ignores the users perception (ignored mine, e.g.) and is not reassuring that
what I wanted to do is actually performed. A strikingly clear usability issue.
If I am told that metadata is preserved, I expect that a cp -r -Pp (with any
additional params required) will actually clone a directory, with data,
symlinks and metadata. IT DOES NOT ----> this IS A BUG.
However, I am aware of the cultural problems that Linux development has, in
which disregard for general-user usability and convenience are common. So that
my expectations to be heard are quite low. As I am interested in the sociology
of Linux, I will try to escalate this little bug (indeed, it is possible to
live with it) to check, for my own education, how widespread this absurdity can
For the time being, I will change the resolution to WONTFIX, which is all what
is happening here. Just you have chosen to ignore the bug, it is not that is
not a bug. Anyways, above are my comments.
See P1003.1's definition of utime(), page 2190 in my copy (line 50962). The
function clearly sets the utimes of the file pointed to by any symlink, as shown
by the potential errors ELOOP and ENAMETOOLONG (second reason). The same goes
for utimes(), and since the only other interface, futimesat(), is defined in
terms of utimes(), that leaves no interface for setting the utime of a symlink.
In fact, the lstat() definition explicitly says that only st_mode and st_size
can be guaranteed to be meaningful when the object is a symlink:
"While the st_uid, st_gid, st_atime, st_mtime, and st_ctime members of the stat
structure may apply to a symbolic link, they are not required to do so. No
functions in IEEE Std 1003.1-200x are required to maintain any of these time
Jim, could you put a note in the man page to briefly explain that
--preserve=timestamp cannot apply to symbolic links?
I've done that upstream with this change:
I have this bug, like all the people.
I have to use rsync -av . And it copies files, symlinks, directories... Just what cp -p should do.
> On most systems, it is not possible to preserve timestamps on symlinks. None of
> the syscalls that do that for other file types can be applied to symlinks; if
> you try, they operate on the pointed-to file, not the symlink.
I don't think rsync programmers are black wizards, do you?
I meant: "rsync -av" preserves the timestamp of the source (even if they are symlinks)... just what "cp -p" should do. So saying "if you try, they operate on the pointed-to file, not the symlink" doesn't apply (and you can try it and see it yourself).
Keeping this bug marked as "CLOSED WONTFIX" is like closing the eyes instead of solving the problem.
thanks for persevering. this will be fixed shortly
I've posted a tentative patch here:
This was fixed in coreutils-7.5, so closing:
WOOOOOOOWWWWW!!!!!! The solution arrived even to Ubuntu 10.10 :-)
God bless you!