[Top][All Lists]

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

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

From: Linda Walsh
Subject: Re: [Bug-tar] Bug? Where? Why? Why so many files changing as we read them?
Date: Wed, 28 Oct 2015 01:13:22 -0700
User-agent: Thunderbird

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:


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.

reply via email to

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