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
