Re: [Bug-tar] Bug? Where? Why? Why so many files changing as we read them?

[Linda Walsh]

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.

>