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

[Piotr P. Stefaniak]

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.

Piotr