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 current time. 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. How reproducible: always Steps to Reproduce: 1. create a tests directory, cd tests cat > file1 contents of file 1 ^C ln -s file1 symlink1 ls -l .... wait 2 minutes here .... cp -Pp file1 file1c cp -Pp symlink1 symlink1c ls -l 2. observe that the date/time of file1 and file1c are identical, while those of symlink1 symlink1c are not. Actual results: different timestamps in source and target symlinks Expected results: same timestamp in source and target symlinks Additional info: None
Fixing component.
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?
Hi Tim, 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 be. 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 fields." 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: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=64f972e94be
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: http://marc.info/?l=coreutils-bug&m=124897071713736&w=2
This was fixed in coreutils-7.5, so closing: http://marc.info/?t=124897089600001&r=1&w=2
WOOOOOOOWWWWW!!!!!! The solution arrived even to Ubuntu 10.10 :-) God bless you!