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

[Piotr P. Stefaniak]

On 2022-06-09 16:41:17, Paul Eggert wrote:
> On 6/3/22 14:47, Piotr P. Stefaniak wrote:
> > 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.
>
> On further thought, I think the flexibility you're suggesting isn't
> needed because pretty much everybody is in your situation, in that users
> don't care about ctime and so don't mind if it changes. Users care
> whether changes to the file mean that the tarball doesn't correspond to
> any state that the file ever had. For this, ctime is a false alarm for
> the reasons you mentioned (adding a hard link).

This looks good to me, thank you. Two minor comments to add:

With the patched GNU tar, my script would still have the chance to abort
when a file's metadata changed but not the mtime field, which in my case
is safe to ignore (I still want the alarm when mtime changes).
Hopefully, the database won't be changing file modes or the like.

People who archive logs still can't tell if the file size changed
because it grew (normal) or shrank (either abnormal or expected but
requiring special handling).

Piotr