Re: [Bug-tar] bug in 'file has changed as we read it'

[Michal Svoboda]

Dustin J. Mitchell wrote:
> If you examine the exit code, you can distinguish this and other
> relatively harmless errors from other, more significant errors.

OK this is a step forward but not good enough. First off, if something
is harmless then it should exit with code 0 indicating no harm has been
done. There just isn't room for 'harmless error' in the return code.

Second, things move from harmless to very serious when there is indeed a
modification of the file *data* 'as we read it'. If I recall correctly,
in such case the consistency of the file is lost. Yet currently there is
no way to distinguish these conditions. (I don't know how amanda deals
with this. If it ignores the error then you're bound to have a bitter
surprise when you least need it, ie. restoring some uber important file
from a backup.)

So what about this:

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)

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


Michal Svoboda