[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Piotr P. Stefaniak
Subject: Revisiting "file changed as we read it", with a proposed patch
Date: Thu, 2 Jun 2022 13:13:19 +0000


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

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.


Attachment: tar-file-changed.diff
Description: Text Data

reply via email to

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