1. Would it be possible to add a condition which would prevent an action from occurring if a previous verify failed? It would be nice to be able to automatically stop actions which could potentially further corrupt a damaged archive.

2. What about adding a "repair if damaged" step to the verify action?

3. I'd love it if you could add Growl support so that completed actions and verification reports could be accessed more easily than launching the app and checking the logs.

Many thanks,

Steve

Steven M. Alper wrote:1. Would it be possible to add a condition which would prevent an action from occurring if a previous verify failed? It would be nice to be able to automatically stop actions which could potentially further corrupt a damaged archive.

That's not necessary. All QRecall commands constantly perform data integrity checks. If a command encounters any inconsistency in the archive data it will stop immediately. A verify is not necessary to determine this.

Once an archive is found to be inconsistent, flags are set in the file headers so that QRecall knows that the archive is bad. At that point, the only two commands you can perform on that archive are Reindex and Repair.

(Actually what happens is that every archive is marked as "bad" as soon as an action begins. If the action completes successfully and finds no inconstancies, the flags are set back to "good" and the archive is closed. If anything interrupts the action -- I/O error, crash, power failure, etc. --- the archive is left with the "bad" flag and will need to be repaired before it can be trusted again.)

2. What about adding a "repair if damaged" step to the verify action?

Repairing requires a number of decisions that should be considered carefully before running it and may have consequences that need to be reviewed once it's done. Running a repair automatically could hide all kinds of serious problems.

Besides, any backup system that needs to automatically repair itself from time to time is simply broken.

3. I'd love it if you could add Growl support so that completed actions and verification reports could be accessed more easily than launching the app and checking the logs.

That's been on my long list of features to add for months.

James Bucanek wrote:
That's not necessary. All QRecall commands constantly perform data integrity checks. If a command encounters any inconsistency in the archive data it will stop immediately. A verify is not necessary to determine this.

Then it's unclear to me why you would run an unattended verify.

Right now I have a Verify action set to run prior to a Compact action. But if the Compact action in essence will check for the integrity of a file, why would this make sense?

Steve

Steven M. Alper wrote:Then it's unclear to me why you would run an unattended verify.

Peace of mind.

The verify command was intended to detect corruption or damage caused by something external to QRecall. When it's done, it guarantees that the data in the archive is readable, valid, intact, and usable.

QRecall is ultra-paranoid about data. Every byte of data in an archive is protected by a checksum, which is verified whenever a block of data is read. The file records all have multiple interlocking verifications to ensure that the directory structure never gets out of sync. So (baring a software bug), it's essentially impossible for a capture or compact operation to add to the corruption of an archive. As soon as any inconsistency is found, the action would stop dead in its tracks.

The verify action is, however, more thorough. A capture only checks the data needed to accomplish the capture. A compact only checks the data that needs to be moved. A verify tests everything, from top to bottom.

So if you had a hard drive that suddenly developed a bad sector, or the disk had cross-linked data blocks, or some malicious program wrote a single zero in the middle of a 300 megabyte archive, a verify would find that while a capture or merge probably wouldn't.

Right now I have a Verify action set to run prior to a Compact action. But if the Compact action in essence will check for the integrity of a file, why would this make sense?

It makes more sense to run a verify following an action that changes the archive. That way you can immediately verify that, following the change, the structure of the archive is still OK.

I do it here because QRecall is still a work-in-progress. Over the past year I've introduced a couple of bugs that caused a capture or merge to vandalize an archive. Regular verifies help me catch those quickly. I also had one of my RAID drives die; the verify caught it before the OS or my RAID monitoring software did!

Steven M. Alper wrote:
1. Would it be possible to add a condition which would prevent an action from occurring if a previous verify failed? It would be nice to be able to automatically stop actions which could potentially further corrupt a damaged archive.

Two suggestions:
1) A slight twist on the original question quoted above. Would it be possible to add a condition which would prevent an action from occurring if a previous verify of another archive failed? Why would I want to do that? Well, in the past I've used backup schedules where - for example - I alternate between two destination archives every other day. Let's say a sw bug should mess up Archive_1 while backing up on Monday, then I have Archive_2 from Sunday still intact However, if I don't realize Archive_1 was corrupted until a few days later, then very likely the same sw bug has already corrupted Archive_2 during Tuesday's backup Now if I could tell QR to not proceed with the scheduled backup on Tuesday in such a case, that might help.

2) Would it be possible and make sense to add a condition that runs an AppleScript and uses a result form the AppleScript to decide whether to proceed or not? Reason, for example: To make sure certain disk images are not mounted, before starting the capture.

Thanks!
- Rene

Interesting suggestions.

I do plan to add some scripting support to QRecall in the not-too-distant future. I think generalized scripting support would allow you to quickly implement these kinds of solutions — and many more I haven't even thought of.

Yes - generalized scripting would seem to be a good solution. Thanks.