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

[Piotr P. Stefaniak]

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
entirety.

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
default.

Piotr