Re: [Bug-tar] spurious "file changed as we read it" error

[Helmut Waitzmann]

Egmont Koblinger <address@hidden> writes:

>On Fri, Aug 03, 2007 at 10:13:10PM +0200, Helmut Waitzmann wrote:
>> I think, it's a kernel bug.
>
>I don't know. Why is it forbidden for example to create a file system that
>spends some idle time trying to look for blocks of full zeros in the
>background and turning them to sparse blocks, hence saving disk space?

If sparse files have equal functionality when compared with files filled
with zeros with respect to an application's point of view (I don't know),
then I can't see any reason why not to use a file system which converts
zero filled blocks into sparse blocks.

But that filesystem must not change the inode change time, when
converting such files.

>However, I still believe it's a bad idea to test for ctime, and I have new
>arguments for this.
>
>ctime is updated in several cases where nothing tar should care about
>happens. For example ctime is updated if you chmod a file to exactly the
>same permissions as it had before. Still you want tar to go on and succeed.

If the permissions don't need changing, then why do you change them?

If permissions have changed, however, then I want tar to archive that
file, when doing an incremental backup.  If tar only looked at the data
change time, it wouldn't notice that change, therefore not archiving that
file.  But see your proposals below.

>Another example is when you create or remove a hard link to a file. As by
>default Linux and AFAIK most other Unix systems allow a user to create a
>hard link to other users' files, this even implies a DoS kind of security
>problem: I can cause another user's tar process to fail when he's archiving
>his files, without having write access to these files!

Yes.  That's a problem.  As traditionally backups have been made by the system
administrator, who could put the machine into single user mode and
remount the file system readonly, it used to be no problem.

To solve that problem, put each user's home directory into a file system
of its own or make the files "immutable" or let the users restrict access
to their files by removing the search permission of the corresponding
directories ("chmod -- go-x DIRECTORY").

As far as I know, granting the users access to the home directories only
via NFS (use for each home directory a separate mount point) inhibits the
creation of hard links across NFS mount points, therefore thwarting such
DoS attacks.

>So I think checking for ctime is a very bad idea. I have two proposals
>instead. First: check for mtime only. Second: compare all the elements of
>struct stat that are relevant to tar: user, group, access mode and so on,
>but not ctime, nr of blocks, hard link count...

Checking for ctime is the only way for GNU to know that the created
archive is a consistent image of the file system's contents.

But why bother checking at all?  If you don't want an archive being a
consistent view of the files, why do you want GNU tar to check for some
file attributes (e.g. mtime) at all?

>> GNU tar maintainers, if you change GNU tar's behavior, then, please, do
>> it by providing an option to switch this new behavior on (and perhaps, an
>> option to switch it off again), not by changing its default behavior.
>
>Can you see any particular situations where you would need this current
>broken behavior? I see no reason to keep backward-compatibility bugs in a
>software.

Someone who appreciates GNU tar's current behavior would have no way to
use GNU tar in a backward-compatible manner.

Maybe, an option to ignore the "file changed as we read it" errors would
help, for example:

   `--ignore-changing=ATTRIBUTE-LIST'
         ATTRIBUTE-LIST is a comma-separated list of file attributes to
         ignore.  The file attributes include mode, nlink, uid, gid,
         size[+-], blocks, atime, mtime, and ctime.  See stat(2) for an
         explanation of the attributes.

         If the size attribute is followed by a `+' or `-' character,
         only increasing resp. decreasing sizes are ignored (for example
         when archiving a log file).

What do you think?
-- 
Wer mir E-Mail schreiben will, stelle   | When writing me e-mail, please
bitte vor meine E-Mail-Adresse meinen   | precede my e-mail address with
Vor- und Nachnamen, etwa so:            | my full name, like
Helmut Waitzmann <address@hidden>, (Helmut Waitzmann) address@hidden