Status and GPG processing questions
robb at canfield.com
Wed Aug 29 00:43:09 UTC 2007
I had to tear into the GPG processing to locate some temp file
anomalies. I found that temporary files are not always cleaned when GPG
is active, and can accumulate at an alarming rate on large backups.
That's fixed along with some memory leaking (minor) problems.
Added improved recover code for backups so that an error backing up a
file/chunk no longer aborts the process. Set via the option --onerror
(default is to halt code).
An error log is now maintained for the run so that if
'--onerror=continue' is given there is still a place to examine for
errors. The name is based on the brackup metafile name with '.err'
suffixed. Logs are maintained for dry-runs as well and they are suffixed
I also found that --dry-run does NOT disable GPG. So the GPG process
manager will happily burn CPU and disk creating files that are then
deleted (via the new clean up code). Should GPG be disabled during dry
runs? I suppose testing GPG on every file to see if it works or not
might be useful, but that seems excessive.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.danga.com/pipermail/brackup/attachments/20070828/29787b68/smime-0001.bin
More information about the brackup