Charles Watts-Jones wrote:Have run the complete set from the Actions window. All OK. Will report again after tommorrow morning's schedule.

Then I would expect it to work. If it doesn't then something else (besides the archive location) is the issue.

When you run an action from the activity window, it actually goes through the scheduler. QRecall (the app) tells the scheduler process to schedule that action to run "now." So there's almost no difference in running an action manually and scheduling it to run at a particular time.

Charles Watts-Jones wrote:As a test I ran the Capture action, it ran flawlessly.

Out of curiosity, did you run the capture action from the actions window or from the File menu?

Using the menu File > Open Recent QRecall opened the archive in its new location.

The Recent Items menu is managed by OS X. How is locates archives is completely different, and independent, of how QRecall locates them.

I must be missing something but what?

I can't think of what. I would suggest that you need to update the location of your archive in your actions, but you seem to have done that already.

The test is to open your actions window and look for actions that are in grey or have a warning icon (see attachment). QRecall's actions window uses the information from the action document to locate the archive, exactly the way the action does when it runs.

If the archive appears grey or has a warning, there are still locations that need to be updated. Open the archive document, select the archive again, and save it.

It they all say they are ready to run, try running them from the action menu (assuming you didn't try that before). If they run successfully, and yet they don't run when scheduled, then something is clearly off. Please send a diagnostic report and we'll investigate.

Hanno,

I downloaded and tested Boxcryptor Classic on a MacPro (10.8.5). Here's what I found.

The Boxcryptor system creates a bundle (Boxcryptor.bc) in your Dropbox/cloud/whatever folder. The package contains the encrypted versions of your files. As you already know, QRecall can capture these just fine.

The Boxcryptor Classic app creates a virtual files system that mirrors those files in an decrypted form. The problem is that the volume doesn't behave like a regular volume.

When I captured the volume, QRecall immediately reports that the volume fails to report its extended attributes (listxattr() returned error 2, which is "no such file or directory"). This pattern gets repeated when QRecall attempts to capture individual files in the volume (file not found and folder not found).

If I had to guess, I'd say that Boxcryptor's implementation of their filesystem fails to support extended attributes and/or the fsIDs used by the Carbon filesystem API to identify objects on a volume. That could explain why QRecall's attempt to open a file or folder return "not found". The next version of QRecall might have better luck, as we're switching to the BSD filesystem API, which tend to be friendlier with foreign filesystems.

Kevin Crawley wrote:The Actions window only shows my new schedule actions.

That's the most definitive indication of what actions you have scheduled. I suspect that your status window (which is run by the QRecallMonitor app) is simply out of sync, possibly related to the problems you've had with your other actions.

Simple solution: Restart your computer.

If you want to try this piecemeal, use the Activity Monitor app. Start by entering "QRecall" into the filter field.

If you don't currently have any QRecall actions running, then there should not be any QRecallHelper processes running. If your find any, Force Quit (kill) them. (If the process is stuck on an I/O error, however, killing it won't work as the process is stuck in the kernel. You will have to hard restart your computer.)

Send a Quit message to the QRecallScheduler process. Then send a Quit message to the QRecallHelper process. Both should stop and then be immediately restarted (they'll have new process IDs when they reappear). If that doesn't happen then it's possible these processes are stuck in the kernel too, and you'll still have to restart your system. (Low-level failures really gum up the works.)

Kevin Crawley wrote:kernel en0: can't handle af8

Googling it brings up nothing. Could it be yours?

Not a QRecall message. (Any QRecall message in the console will have a QRecall process name associated with it.)

en0 is the first ethernet adaptor. Probably something to do with IP traffic.

Kevin,

I regret to say it, but I suspect that your hard drive is dying. There may be I/O errors in QRecall's log, and you're welcome to send a diagnostic report, but from what you describe it would appear that your hard drive is encountering read failures when trying to read certain regions of the platter—specifically, those that the QRecall archive occupies.

When I test it with the Disk Utility or with Disk Warrior, they tell me the disk is okay ...

Disk Utility, Disk Warrior, and almost every other disk utility out there, only validates the directory structure of the volume. They do not perform a comprehensive read/write test to confirm that all sectors of the drive are usable. You could lose a third of your drive, and Disk Utility will still report that it's fine. Any utility that reads the entire surface would require hours (and hours) to run. This is why QRecall's verify action takes as long as it does.

If you're interested in testing this theory, it's pretty easy from Terminal. You can run a simple command to read all of the data in the archive. If it's successful, it will finish after an hour or so. If there are I/O failures, the command should stop and spit out an error.

cat /Volumes/My3TBExternalVolName/pathtoarchive/ArchiveName.quanta/* > /dev/null && echo "No read problems"

Be patient. Even if it works, it will take a long time to finish. If the drive is encountering I/O failures, it will likely enter a retry/recalibrate cycle where it attempts to realign the heads and try again. Drives that are doing this run about 1,000 times slower than normal, so even if it hits an I/O error it could be many minutes before it's reported. You may hear the drive heads seek and clatter during this process. You can monitor the progress using Activity Monitor (switch to the Disk Activity tab) to see if it's still reading the drive or if the command has stalled. (Press Control-C in the Terminal window to kill the command.)

If you verify that it's I/O errors, you can attempt to recover the archive. You'll need a second volume with enough room to copy it. Choose the Repair Archive... command. Uncheck the "Use auto-repair information" option. (This is probably where your repair is getting stuck now.) Check the "Copy recovered content to new archive" and "Recover lost files" option.

This configuration will doggedly try to read every record in the original archive. Every record that can be read will be copied to the new archive. QRecall will then assemble the salvageable data into a usable archive. The "Recover lost files" option will collect orphaned files—files that don't belong to a folder because all of the folder information was lost—into a special "Recovered files" volume.

If the drive has a lot of damaged areas, the repair could run for days before it completes. So again, you'll need to be patient.

Wayne Fruhwald wrote:I will attach each of the drives to my MBP and capture them interactively, one at a time.

If these are all removable drives, I would suggest creating a capture action for each volume. Use an event schedule to start the capture when the drive connects, repeating once or twice a day. Whenever you connect a drive, its changes will be automatically captured.

You can set all of the actions to capture to the same archive.

I want to set QRecall settings such that the searches will be as fast as possible (considering that I have 16 GB RAM).

Searching an archive is fundamentally bounded by I/O. Archive search speed is affected most by the seek time of the drive containing the archive.

I want to be able to perform the following searches:
1. Search across ALL drives using the most recent layer of each (i.e. the most recent capture of each drive which will be in different QRecall layers)
2. Search across ALL drives using ALL layers so that I can find deleted and modified files

When you perform a search, you are searching within the items contained in the navigation bar location (at the bottom of the browser window). So if the navigation bar location is My Computer > Main HD > Users, the search will be limited to the items in the Users folder of the Main HD drive.

To search a single volume, navigate to the root directory of that volume and perform your search.

To search multiple volumes (belonging to the same owner), navigate to the owner and perform your search.

I find the search option "Only Show Matching Items" useful when searching entire volumes or top-level directories.

To include or exclude deleted items in your search, choose View > Show/Hide Deleted Items.

The browser will display the timeline of the earlier versions of each item via the layers pane, whether you're searching or not. You don't really "search all layers"; that happens implicitly. You simply search for an item, and then browse the versions of that item.

3. Search across one or more drives using the most recent layer of each
4. Search across one or more drives using ALL layers so that I can find deleted files

You can search all volumes or one volume (as described), but not an arbitrary set of volumes. Of course, searches are interactive. You can start a search and switch volumes, which will resume the search in that volume.

Ralph Strauch wrote:Unfortunately, I didn't think to look at the dates of the files I deleted, and they don't seem to be showing up in "deleted files."

They won't show up as deleted files because you deleted them from the archive. A "deleted file" is a file that's been captured, but was later deleted on the source volume. But once removed entirely from the archive, it no longer exists in any form.

The second edition of Take Control of Backing Up Your Mac is now available.

Included in the book is a 40% coupon off your next QRecall identity key purchase, a $16 value.

Ralph Strauch wrote:It occurred to me recently that there's no reason to back up my sleepimage or my swap files, so I opened my archive and deleted those from the archive.

Your swap files and sleepimage file should be automatically excluded from captures.

One of the fixed, built-in, exclusion filters is the VM filter. When QRecall starts a capture, it examines the arguments passed to the dynamic_pager process. If a specific directory was specified, it excludes that directory from the capture. If it can't determine which directory the dynamic_pager process is using (or it can't find a dynamic_pager process), it excludes the contents of the /var/vm directory.

You can manually specify the location of the swap files by setting the QRVMSwapStorePath advanced settings to the path of your swap files. See the Advanced Settings page for the details. If you've set this property, and you're swap files are not being excluded, then consider changing it or deleting the setting and see if QRecall can determine the location itself.

If everything seems in order and QRecall isn't excluding the contents of your VM swap directory, I'd very much like to know about that.

Finally, when adding excluded items to a capture action, holding down one or both of these keys will modify the behavior of the + button:
Option allows you to exclude invisible items
Shift allows you to exclude items inside packages

Bob Tyson wrote:May I respond to your 'hint' also with this, a slight 'gripe' which is that searching the help on 'status window' produces nothing useful in this regard.

This might be your Spotlight system. A search in my QRecall help window results in two QRecall hits: Monitor Preferences and Status Window, which is exactly what I would expect.

Help indexing is performed by Spotlight, so your spotlight database might not be updating or it's just taking its time.

Bob,

You probably have stale status information. QRecall caches a copy of the archive's status (so it can be displayed when the archive is off-line). If the path/alias to the archive has changed, the copy of the status gets disconnected from the actual archive and you end up with two statuses—one active and one stale.

Bob Tyson wrote:One reason is that after formatting an archive volume and making a new backup that failed, and produced warning messages, I trashed that faulty QR archive file and re-created a new one in QR, then made an action that completed the new complete archive and subsequently an incremental backup. The whole process proceeded quickly and the status window reports this most recent archive and backup cycle as healthy.

Now I know this is what's happened. Reformatting a volume is almost guaranteed to break the alias records that QRecall uses to locate archives.

Open the archive status window. Find the stale ones (they will report that they haven't been captured or verified in days or weeks), right/control+click on one, and choose Forget.

Forgetting a status is always harmless. It simply discards the cached copy of the archive's status. If you forget an active archive, there's no harm; it will reappear in the list the next time it's captured or verified.

Tip: Right/control+click on an archive's status. If the "Reveal in Finder" command is disabled, then QRecall can't locate the archive this status belongs to. Either it's off-line or the connection between the status and the archive is broken.

You can find a little more about the status window in Help > QRecall Help > Guide > The Basics > Status Window.

Ralph Strauch wrote:What can I do to "close" the archive so that I can access it again?

The surgical approach: Find out what process has the file(s) open. You can use the lsof (list open files) command-line tool. Run the command, as root, on the system that hosts the QRecall Archive. The following command lists all of the open files, and what processes has them open, inside the folder /Volume/Hard Drive/Archive.quanta:

sudo lsof +D '/Volumes/Hard Drive/Archive.quanta'

Once you discover the process that has the file open, restart it (probably your network file server).

The hammer approach: Restart your computer

If you've made sure that no other process has the archive files open, and the QRecall actions still won't run, you may have an orphaned .lock file. The Repair action will fix this, but you can also just delete it via the command line or any utility that will let you see, and trash, invisible files:

rm '/Volumes/Hard Drive/Archive.quanta/.lock'

Peter B. wrote:If QRecall knew that an original has changed, but it shouldn't have since the last capture (because the modification date of the original is the same as the one in the archive), then QRecall could alert the user that the original may be corrupted.

Unfortunately, the only way to do that would be read every file that didn't appear to have been modified, in its entirely, every time you performed a new capture. This would require (approximately) the same amount of work as recalling the entire volume, during every capture. It would make more sense—and be a heck of a lot less work—to just keep your incremental changes longer.

The only instance I can remember where this happens is with AppleScript Editor in Snow Leopard when modifying scripts saved as applications.

That's a different issue. An application is a bundle (a folder that appears to be a single file in the Finder). The modification date of the bundle is the modification date of the bundle's folder, which may, or may not, reflect the modification dates of its contents.

This is a non-issue for QRecall. QRecall does not use the modification date of a folder to determine if the contents of that folder have changed.

Peter B. wrote:Control option controls the top shade

The help has been corrected. Thanks!

control command controls bottom shade.

Control+arrow moves the bottom shade. The command key is ignored.