[Top][All Lists]

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

Re: cp -p loses precision on the timestamp of the copy

From: Bob Proulx
Subject: Re: cp -p loses precision on the timestamp of the copy
Date: Sat, 2 Feb 2008 19:11:57 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

Ray Liere wrote:
> Below is the information that you requested. I do realize that this
> version of coreutils is not current (as has been pointed out by Eric
> Blake), so if this is a known problem being addressed/already
> addressed, that is good enough for me.

Things are complicated.  It is not that it can't work but rather that
there are combinations that definitely don't work, while at the same
time others do.  Things get better as microsecond support matures.

And your information here shows that you are running a linux 2.6.9
kernel with the ext3 filesystem.  As far as I know there was no
microsecond support available in that combination.  At least there
isn't on my system.

However you are actually running a patched version 2.6.9-5.EL for
RHEL.  Therefore I infer that what is there was patched in by Red Hat.
I am guessing this provides early support for microsecond timestamps.
Because of this I suggest that you report your issue to RH.  If my
guess is correct and it was patched in then perhaps they would update
their patch to address this problem.  And if I am wrong then that is
still a reasonable course of action.

> I was thrown by it because I had written some code that "assumed"
> that, regardless of what timestamp precision existed on a particular
> computer, all of linux would be consistent and either use the extended
> precision or not.

In a perfect world that would be true.

> # strace -e trace=file cp -p jnk jnkcopy2
> stat64("jnk", {st_mode=S_IFREG|0600, st_size=4, ...}) = 0

Unfortunately I did not ask you to run 'strace -v' to get all of the
data or we would be able to see the time value of the file there.
Without -v we only see abbreviated data.  But okay here regardless.

> utimes("jnkcopy2", {1201833653, 245502}) = 0

The cp command is trying but the kernel is not listening.  The first
parameter is the seconds.

  date -d @1201833653 '+%F %T'
  2008-01-31 19:40:53

The second parameter is the microseconds.  Because cp is setting it I
believe that cp is working correctly.  At that point if the timestamp
does not show up on the file then it can only be the filesytem in the
linux kernel that is not handling the data in the system call.

I suggest that you report this to Red Hat and see what they say about
the issue.


reply via email to

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