[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, 10 Jun 2022 08:00:33 +0000

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


reply via email to

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