[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 10:13:11 +0000

On 2022-06-02 17:06:32, Paul Eggert wrote:
It sounds like something like this would be a good thing to have.

A few thoughts.

1. If the mtime or size changes, doesn't this necessarily mean that
ctime changes? In other words, isn't tar's current test for size growing
redundant? This test was added in commit
c455373e5b7fc3037ad9e4204ba6c6aac2faa10f dated Oct 14 21:11:27 2006
+0000 but it's not clear to me why it is needed now.

Your question sounds reasonable. I checked stat.2 on FreeBSD and inode.7
on Ubuntu and from my reading the assumption should be guaranteed
correct on those two systems.

Perhaps I could drop size+ from the default then.

I don't have the resources to verify if this is true on all other
operating systems that you want to support.

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.
We could extend my patch to include more status fields (for example
permission-related fields) and group aliases (for example PERMISSION).

The way flags are handled for --warning and in my proposed patch for
--file-changed is clumsy because flags accumulate. I think it would help
if we could break from the convention and use something similar to
--file-changed=mtime,permission abandoning the accumulative property.


reply via email to

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