jidanni.org> writes:
>
> Fellas, in http://bugs.debian.org/276500
> m> There is a new syscall in 2.6.22, utimensat. It gets a "struct timespec"
> m> which allows nanosecond resolution.
> That means you can now fix the difference in
> $ touch m; touch -r m n; stat -c %y m n
> 2008-06-24 06:13:24
Fellas, in http://bugs.debian.org/276500
m> There is a new syscall in 2.6.22, utimensat. It gets a "struct timespec"
m> which allows nanosecond resolution.
That means you can now fix the difference in
$ touch m; touch -r m n; stat -c %y m n
2008-06-24 06:13:24.106160298 +0800
2008-06-24 06:13:24.10
P> The basic problem is that utimes() has only microsecond resolution;
P> the kernel need to add a system call ("utimens()", say?) that
P> supports nanosecond resolution.
Dudes, I have discovered that after a reboot, (stat(1)) differences like
Modify: 2004-12-10 23:28:07.877053000 +0800
Modify: 20
Dan Jacobson <[EMAIL PROTECTED]> writes:
> Sure hope microsecond differences seen by
> touch -r a b; stat -c %y a b
> are fixed by it too.
"touch" operates by means of system calls. If the system calls
mishandle submicrosecond time stamps, "touch" will as well. So you'll
have to direct your bug
P> Here's a patch:
P> http://lists.gnu.org/archive/html/bug-coreutils/2004-03/msg00095.html
I see, at present there is only a patch, no actual release containing
the fix, that say the Debian provider would then distribute, I suppose.
Sure hope microsecond differences seen by
touch -r a b; stat -c
Dan Jacobson <[EMAIL PROTECTED]> writes:
> # stat -c %y m o
> 2004-10-10 01:56:36.561517778 +0800
> 2004-10-10 01:56:36.561517000 +0800
> which must be the key to why cp -up will update repeatedly.
Yes, that most likely explains it. Here's a patch:
http://lists.gnu.org/archive/html/bug-coreutil
Here on debian sid coreutils 5.2.1-2 we see back digits are not tended to:
# touch -r m o
# stat -c %y m o
2004-10-10 01:56:36.561517778 +0800
2004-10-10 01:56:36.561517000 +0800
which must be the key to why cp -up will update repeatedly.
Some lines from the strace you wanted:
fstat64(4, {st_dev=m
Dan Jacobson <[EMAIL PROTECTED]> writes:
> Perhaps fixed already?
I don't get that behavior with my copy of coreutils 5.2.1
(which I built myself under Debian GNU/Linux 3.0r1).
Can you investigate why it's happening for you?
Try running "strace -v cp -upv g h" and looking
at the last few lines o
