I back up both a MBP and an iMac to the same archive, and the paths to excluded items in my archives seem to depend on which computer I'm looking at them with rather than on which drive the files are actually on. For example, I have a folder named "don't backup" on the desktop of the MBP, and when I open the archive on the MBP the exclusion shows up as -/Desktop/Dont backup, while on the iMac, the same exclusion shows up as iMacHD/Users/ralph/Desktop/Dont backup. (The full path shows up here because I'm backing up the iMac from my wife's account and it's pointing to a nonexistent file in my account.) The same thing is true in the other direction, Excluded files on the iMac show up on the MBP as nonexistent files there.

I guess this may work out OK in practice because the files that need to be excluded are the ones on the computer doing the backup and those paths are correct, so the paths to nonexistent files that are really on the other computer just get ignored. It can be confusing, though, to look at the exclusions list and see a bunch of nonexistent files.

Related problem: Because I didn't have my exclusion lists properly sorted out in one of my archives, a large bunch of normally excluded fine on the iMac got swept into my backup and ran my drive out of space. I started deleting them from the iMac, which is USB2, then realized that I could do it much faster from the MBP, which is USB3, so I moved the backup drive to the MBP. From there, when I open the archive and select a file to delete, but when I hit the Delete button I get a window that says "Waiting for Archive," and nothing happens. It's telling me this while the archive is sitting there open in front of me. What's blocking the delete function on the MBP? (report sent)

Ralph Strauch wrote:I back up both a MBP and an iMac to the same archive, and the paths to excluded items in my archives seem to depend on which computer I'm looking at them with rather than on which drive the files are actually on.

That's expected. QRecall 2.0 uses URL Bookmarks to identify and remember items in places like the archive preferences and actions. Bookmarks work really hard to identify an individual file or folder. Thus, when viewed on a different system, the bookmark will resolve to the same item, but that item might have a different filesystem path.

I guess this may work out OK in practice because the files that need to be excluded are the ones on the computer doing the backup and those paths are correct, so the paths to nonexistent files that are really on the other computer just get ignored. It can be confusing, though, to look at the exclusions list and see a bunch of nonexistent files.

It kind of has to work this way, else you run into the inability to exclude a folder on one system and not exclude it on another.

In a nutshell, the best way to exclude items using the archive settings on multiple systems it to open the archive on the first system and add the items to be excluded for that system. Close the archive and repeat with the next system.

Alternatively, you can use the new QRecall Capture Preferences to exclude each item individually.

The exclusions will work fine, I think, now that I understand the way it works. It was just a shock to see them looking like they were pointing at the wrong disk, and not understanding why.

I'm still having trouble deleting items from the archive to clean it out. I first thought it might be because I didn't have enough headroom, but I took a second archive off the drive and now have 400+gb free space and still get "waiting for archive" when I attempt to delete an item. I'm thinking about start a repair as my next step. Is there anything simpler I should check first?

Ralph Strauch wrote:Related problem: ... From there, when I open the archive and select a file to delete, but when I hit the Delete button I get a window that says "Waiting for Archive," and nothing happens. It's telling me this while the archive is sitting there open in front of me. What's blocking the delete function on the MBP? (report sent)

This has been mentioned in another thread, but it bears repeating.

Short answer: be patient.

Long answer:

QRecall 2.0 uses a new method for arbitrating access to an archive between current actions and multiple users. Inside the archive package is a new set of invisible semaphore files (.lock, .share, and .semaphore). These files allow QRecall to negotiate access to the archive on devices that don't support the shared-read/exclude-write access control required to safely share the files.

One problem is that these files can become "stale" and indicate that the archive is being accessed by another process when it isn't.

The next action to request access to the archive sees the stale lock and you get the "Waiting for archive" message. Behind the scenes, it begins a series of tests to determine if the archive really is being used. These tests take about 10 minutes to determine that no other process is modifying the archive and the lock is stale. Once it's convinced that it's safe to access the archive, it will "break" the lock and acquire the access it needs.

So, just let it "wait". It will eventually determine that it can safely access the archive and the action will proceed.