Jon LaBadie wrote: > Is this a problem you are having or just something you understand?
*ouch*. Please excuse my writing style. ;-) > On most of my systems this non-zero status is not a problem. On my cygwin client > it did cause problems so I modified tar's source code to force a zero exits status. Unfortunately, on the majority of my clients tar returns non-zero exit status, so i will have to find a workaround. I have received three suggestions so far: 1. Hack tar to force it to return a non-error status I think 1 is the best option for systems that only have logfiles, since the only thing that would be missing in the backup is the appended lines, which would be backed up the next day in any event. Q. Is there modified tar source posted somewhere on the net by some kind soul? 2. Ignore files which change size during a backup This one is the least likely option, as even logfiles can be important. 3. Take a snapshot of the system before backing it up. On systems that have files whose entire 'state' changes, it seems this is the most reasonable solution. Examples of this would be databases or hash files, etc., in which case a shell script could be written to take care of this before the backup runs. Q: What do you do for large files which are constantly changing? for example, one of my files is 800MB and its 'state' changes fairly regularly, resulting in failed or inaccurate backups. I haven't figured out what to do with this one. I don't know of any way to 'lock' the file during a backup procedure, or even while copying it somewhere else, for that matter. Does anyone have a suggestion here? Thank-you so much for your help! cheers, john.
