[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: Paul Eggert
Subject: Re: Revisiting "file changed as we read it", with a proposed patch
Date: Thu, 9 Jun 2022 16:41:17 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

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

With that in mind I installed the attached patch into GNU tar's master branch on Savannah. I think this addresses the issue you mentioned, because the patched GNU tar won't warn at all in that situation. This also fixes some other issues that I noticed while in the neighborhood (see the NEWS file and the commit message).

Comments welcome.

Attachment: 0001-Warn-file-changed-as-we-read-it-less-often.patch
Description: Text Data

reply via email to

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