This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 230866

Summary: cp -Pp does not preserve the timestamp of the source
Product: [Fedora] Fedora Reporter: Polo Talnir <polo_talnir>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 12CC: d2856653, d3325879, meyering, polo_talnir
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Fedora 12 (coreutils-7.5) Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-16 12:31:58 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Polo Talnir 2007-03-03 19:12:14 EST
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
Comment 1 Tim Waugh 2007-03-09 08:17:37 EST
Fixing component.
Comment 2 Tim Waugh 2007-03-09 08:45:53 EST
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?
Comment 3 Jim Meyering 2007-03-09 10:43:54 EST
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.
Comment 4 Tim Waugh 2007-03-09 10:59:15 EST
Alright, let's leave it as it is.
Comment 5 Polo Talnir 2007-03-10 16:57:08 EST
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.
Comment 6 Tim Waugh 2007-03-12 07:27:32 EDT
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?
Comment 7 Jim Meyering 2007-03-12 09:30:34 EDT
I've done that upstream with this change:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=64f972e94be
Comment 8 Junan 2009-06-02 05:21:13 EDT
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?
Comment 9 Junan 2009-07-27 04:08:04 EDT
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.
Comment 10 Jim Meyering 2009-07-27 05:17:10 EDT
thanks for persevering.  this will be fixed shortly
Comment 11 Jim Meyering 2009-07-30 12:23:52 EDT
I've posted a tentative patch here:
http://marc.info/?l=coreutils-bug&m=124897071713736&w=2
Comment 12 Jim Meyering 2009-11-16 12:31:58 EST
This was fixed in coreutils-7.5, so closing:

http://marc.info/?t=124897089600001&r=1&w=2
Comment 13 Junan 2010-10-22 09:00:55 EDT
WOOOOOOOWWWWW!!!!!! The solution arrived even to Ubuntu 10.10 :-)

God bless you!