I'm trying to run a backup action on my iMac and qrecall just sits there "waiting for archive." The backup disk is mounted, the archive shows up in the finder, and I can even open the archive with qrecall and perform a manual merge operation. When I try to run an action, though, it just sits there "waiting for action." This happens with a merge action as well as with the backup. I tried opening the action, reselecting the archive, and saving the action, and that didn't help.

A backup action to a different archive does work, so it's just this one particular archive that fails.

Ralph

Have you checked that the action is still pointing to the correct archive? I had an instance where for reasons unknown an action ended up pointing to some obscure file.

Adrian

As Adrian pointed out, it's possible that the action is pointing to a different archive. QRecall uses OS X alias objects to track the location of archives, and they can be tricked into referring to the wrong file.

I suspect, however, that some other process has the file open for reading.

Browsing, verify, and recall actions access the archive using shared read permission. That means that any other process can be reading from the same archive, but no process is allowed to write to it.

Merge and capture actions access an archive using exclusive write permission. That means that no other process is allowed to access the file for reading or writing until the action is done.

If an action can't obtain the access permission it needs, it displays the "Waiting for archive" message and ... waits.

To find out what other processes are accessing your files, open a Terminal window and issue the following command:

sudo lsof | fgrep 'FragmentOfArchiveName'

The lsof tool "lists the open files" on your system and the process name that has them open.

Here's an example from my system:

sudo lsof | fgrep 'Teacup'

QRecallHe 6548          james  txt       REG              14,19     67108868       8798 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/negative.index

QRecallHe 6548          james    5u      REG              14,19 155538852120       8806 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/repository.data

QRecallHe 6548          james    6r      REG              14,19     56868912       8802 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/package.index

QRecallHe 6548          james    7r      REG              14,19     75446504       8793 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/filename.index

QRecallHe 6548          james    8r      REG              14,19        25944       8792 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/displayname.index

QRecallHe 6548          james    9r      REG              14,19    402653240       8795 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/hash.index

QRecallHe 6548          james   10r      REG              14,19     67108868       8798 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/negative.index

QRecallHe 6548          james   11r      REG              14,19        83438       8796 /Volumes/Warehouse 13/Backups/Red King/Teacup.quanta/hash_adjunct.index

This is telling me that a QRecallHelper process has a bunch of files open inside my Teacup.quanta archive bundle. This is normal, as the QRecallHelper was performing a verify of the archive at the time.

One all-too-common scenario is when an archive is being shared using file sharing. A process on a remote computer opens a file, and then the connection (ethernet or Wi-Fi) is lost. The Apple File Server process keeps the local file open, thinking that the remote computer still has the file open. When this happens, the lsof command will tell you that the AppleFile process has the file open.

The solution is to simply restart the computer sharing the file (closing all open files), or to stop and then restart the file server (again, causing the file server to first close all files). The later can be done in the Sharing preferences pane.

I had reselcted the archive in the action before I posted, so was pretty sure it wasn't that. Using lsof returned only Finder using the archive as a whole. Restarting the computer did the trick, though, and it's working now.

Thanks for the prompt response.

Ralph

Oops, I somehow missed that you had already reselected the archive. I really must do something about these darned spectacles.

Ralph Strauch wrote:I had reselcted the archive in the action before I posted, so was pretty sure it wasn't that.

I feel compelled to point out that changing an action document after the action starts has no effect on the action that's already running.

If the action had been started and was reporting "Waiting for archive," the process for that action has already been created and won't be influenced by changes to the action's definition until the next time it runs. You would need to (1) change and save the action document, (2) stop the running action, (3) run the action again.