Paul Eggert wrote:
One possibility is that the file system is buggy, and that reading a
file (and therefore modifying st_atime) also modifies st_ctime as a
side effect. Often this sort of thing is delayed, that is, you read a
file and its st_atime is updated immediately, but its st_ctime is
updated after a delay of a few seconds. This would explain the
observed behavior.
AFAIK (but with MS, who really knows anything?), MS adopted a similar
system to the linux
kernel in regards to updating last-access times when atime updating is
turned off. I.e.
I thought that the kernel opportunistically updates last-access if
something else changes in
the inode to be no earlier than the ctime or modtime fields.
I just read last week in looking at MS notes on NTFS implementation,
that it does
something similar when don't have last-access turned off -- but it may hold
off on the writing out of the last access time for up to an hour --
trying to wait
for a time when one of the other times is updated.
But that said -- I don't get the same messages when I run tar on the
client-MS
machine. Instead I get failures to read ACL's and ext-attrs... which is
maybe worse.
But it's only when I use the linux CIFS to access the remote NTFS that
tar gets upset.
So I don't think it is the source FS.
See, for example:
https://bugzilla.redhat.com/show_bug.cgi?id=1058526
which does indeed illustrate remote file-system bugs that can cause
the behavior in question. (Mark O'Keefe's proposed change to tar isn't
right; there are security reasons to worry about ctime as opposed to
mtime).
Well -- I have yet to try to use stat on all the files b4 and aftr ...
keep getting sidetracked.
