[Top][All Lists]

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

Re: Revisiting "file changed as we read it", with a proposed patch

From: Piotr P. Stefaniak
Subject: Re: Revisiting "file changed as we read it", with a proposed patch
Date: Fri, 3 Jun 2022 21:47:16 +0000

On 2022-06-03 14:19:09, Paul Eggert wrote:
On 6/3/22 03:13, Piotr P. Stefaniak wrote:

2. How about a simpler option which basically says: warn only about
changes to any of the following: st_mtime, st_uid, st_gid, st_mode,
st_size. It's not clear that the extra complexity of a more-complicated
option is worth the aggravation.

This wouldn't be perfect for my use case; I want my shell script to
abort execution (set -e -o pipefail) iff tar observes a content change
in the file that is expected to never change.

Sorry, I'm not quite understanding.

First, if I understand things correctly, the patch you sent won't cause
'tar' to abort execution, only to issue a warning. Or are you saying
you'll send tar's stderr to a pipe with no reader, so that the warning
will cause 'tar' to exit? If so, that sounds less reliable than it could be.

GNU tar already returns the exit status of 1 when it's found out that at
least one file changed while being archived but the archival process was
otherwise successful. Please recall dump_file0() in create.c calling
set_exit_status(TAREXIT_DIFFERS); when the conditions for a "file
changed while we read it" are met.

This is what stops my script, because I run it with set -e -o pipefail.

I could ignore the exit status of 1 and it's actually what I'm doing
now, but I think we can do better because this has already made multiple
people analyze this behavior. You can see comments in the bug report
I mentioned talking about replacing the use of GNU tar with BSD tar as
a workaround, because it only returns 0 on success and 1 on error (GNU
tar returns 0, 1 or 2).

And in principle it would have been the desired behavior if I got to say
what it means for a file to change. In my particular case, it's safe and
preferable to ignore situations where ctime changes (permission update,
hardlink count change, etc.) but mtime does not. But I do want to learn
when mtime changes because that's a bug in the database and I ought to
report it.

This is why I believe we, the users, could use some flexibility here in
GNU tar options relating to this.

Second, I know you're not suggesting the only perfectly-reliable way to
know the content hasn't changed, which is to save a copy and compare the
content to the saved copy. Instead, you're suggesting a heuristic A that
involves looking only at the mtime and size. That differs the heuristic
B that I suggested, in that B generates a warning if the file's uid,
gid, or mode changes, whereas A does not. In your use case, why is it
harmful for B to generate those extra warnings?

Because generating a warning is not the only thing it does, it also
returns the exit status of 1 and by doing so, stops my script (and those
of others) from taking the backup of the database file set in its

And perhaps to prevent a misunderstanding, what I'm proposing does not
change the default behavior, but it does give users an option to change
the meaning of a file change to suit their situation better than the


reply via email to

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