Status and GPG processing questions

[Richard Edward Horner]

Robb,

Awesome work.

I had actually suspected there might have been an issue with this when
David posted his problem, hence my asking if he was using GPG.

On the --dry-run issue, I think ppl expect it to tell you what would
be done but not do things. If you read the man page for many ppl's
favorite package manager, apt-get, which I think would be a good point
for establishing expected behavior, it says:

--dry-run
No action; perform a simulation of events that would occur but do not
actually change the system.

"No action" is pretty clear but "perform a simulation" isn't exactly
the same as "no action". Sorry, I come from a family of lawyers.

Usually when you do a dry run on something, you just want to quickly
see what it would do, so not invoking GPG would be beneficial cuz it
would be faster and also if you're invoking --dry-run cuz you're
trying to back up a failing disk and you're not sure how many more
read/writes you're gonna get, having it do anything is not good. I
would be inclined to say have it really do nothing more than print
messages to the console. If you want further action, there can be
another flag.

Thanks, Rich(ard)

On 8/29/07, robb <robb at canfield.com> wrote:
> 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
> with '-dry.err'.
>
> 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.
>
>
>


-- 
Richard Edward Horner
Engineer / Composer / Electric Guitar Virtuoso
rich at richhorner.com
http://richhorner.com - updated June 28th