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

[Piotr P. Stefaniak]

Hello

This topic comes up every couple of years and I guess it's that time
again.

I was prompted to look into this due to a perplexing interaction between
a database that is supposed to only create immutable database files and
another process that tries to create a backup from hardlinks pointing to
those files. The surprise here are tar reports that the file changed.

After reading https://issues.apache.org/jira/browse/CASSANDRA-17473 I'm
almost sure that it's ctime changing in the meantime due to the original
hardlink getting removed (due to a process this database system calls
compaction) while tar is processing the blocks.

Therefore I would like to propose the attached patch for inclusion in a
future version of tar.

It improves the granularity of what the user can define as a file
change; for now I added size+, size-, mtime, and ctime. The original
behavior is kept as the default (and equivalent to --file-changed=none
--file-changed=ctime --file-changed=size+).

I made --file-changed work like --warning, and although I'm not the
biggest fan of the UX it offers to the user, it's at least consistent
with an existing option.

I documented this change in tar.1, but didn't add any tests.

Piotr

tar-file-changed.diff
Description: Text Data