On 09/13/10 07:34, Michal Svoboda wrote: > 1) if the ctime changed, hum something on stderr, do NOT change retval > to 1, and be consistent with the meta-data included in the archive (ie. > always include the old inode contents)
There are applications where it's important that the metadata be consistent with the data: for example, it could be that the data contain time stamps, which should always predate the ctime, and if the tar image contains data with timestamps after the ctime, then the tar image is inconsistent. Perhaps an option could be added to tar to selectively control the seriousness of each warning; that should address the problem. > 2) if the mtime changed, hum something else, change error code to 1 (or > greater if you want), do not guarantee consistency of the archive Tar itself cannot guarantee the consistency of the archive, no matter what we do about this little problem. There are ways to guarantee consistency, such as mounting the file system read-only before dumping it with tar, but they're outside the scope of tar itself.
