I've been having trouble with a rather large QRecall archive: 1.75 TB. After attempting a regular 'verify' my external drive unmounted itself and of course QRecall ended up aborting. Since then I've tried three times to run a 'repair', but after about 7h running, in each case the external drive unmounts and sooner (or rather later!) QRecall aborts. The most recent log is 14 GB so not easy to handle, but I have extracted the start of the log and the bit in the middle where the 'unmount' occurs - it really looks like somehow it is QRecall that is issuing the unmount commands?! Does this make any sense? The weird thing is that the unmounts always occur after the same amount of QRecall's running time, about 6h 30m in. I am running Amphetamine, to prevent any issues of the drive 'sleeping' etc.

Right now I cannot open the archive in QRecall. It has suggested I reindex and that is running right now.

My external is a 4 TB Seagate, partitioned into 2 x 2 TB. The QRecall archive is on one of them ('Seagate_1').

Any advice or suggestions other than dumping the archive and starting from scratch?

Thanks,
Tim Cox

Tim,

I'm sorry to hear you're having problems.

I suspect the problem is in your hard drive (hardware). Less likely, it might possibly be a bug in the some of the special software you're running—although, honestly, I can't image how.

QRecall definitely does not issue unmount requests to volumes that are being verified or repaired. And even if it did, it wouldn't matter; software can only request that a volume be unmounted. The filesystem will refuse that request if there are still open files—which is obviously the case here.

The only way for a volume to get unmounted while you have open files is a spontaneous loss of connection with the device, and this is usually a hardware issue. (Full disclosure: there have been a few OS bugs that caused this too—like the infamous "FireWire sleep" bug—but right now I'm not aware of any).

We'd be happy to help you look for clues in your logs, but we'll need a lot more context. Start by sending a diagnostic report (in the QRecall app, choose Help > Send Report). Then locate your QRecall.log file, compress it, and then use a file transfer service like We Transfer to send the compressed file to support@qrecall.com.

Thanks for the rapid reply.

This business about unmounting drives is very strange. It just never happens, and now it seems to happen semi-reproducibly in this situation with QRecall verify or repair.

I've sent the report.

And the zipped log is on Dropbox
https://www.dropbox.com/s/b7halopjxe0tgli/190330_QRecall.log.zip?dl=0
(647 MB of my 2 GB quota, so I won't keep it there for more than a few days!)

I would appreciate it if you could let me know of anything you learn.

The reindexing of the archive completed without any issue, and I can now view it. I think I'll stop updating it. It has 2 years-worth of backups for my MacBook Pro in it, Time to start a fresh one, I think!

Regards,

Tim

Tim,

If the reindex was successful, then your archive is fine. Also, a reindex and a verify require about the same amount of time/effort which lends to the theory that this is a semi-random event.

When I get reports that a drive is un-mounting in the middle of long action (like verify) but not for other actions, I also look to the possibility that it is un-mounting at other times and there's simply no process to notice.

If you're handy in the Terminal, you might occasionally use something like fgrep 'mounted volume' ~/Library/Logs/QRecall/QRecall.log* | fgrep Seagate to look for times when your Seagate drive(s) unmount at unexpected times. (The log you uploaded only covered two days, which isn't enough time to catch something like this.)

If you find these scattered around, I suspect your drive has been spontaneously unmounting all along but only causes grief when it intersects a long running action like a verify or repair.

Thanks for confirming a successful reindex means the archive is good. I'll save it as a backup and start a fresh one, I think.

The reindexing seemed to complete much more rapidly than the verify - it took <5h. My attempts at a verify, and 3 failed repair attempts all ran for over 6h before the unmounting errors aborted things.

I'll try your suggestion for monitoring random unmounts of my Seagate. I've had some random unmounting issues with various external SSD drives on my 2016 MacBook Pro but I had thought the Seagate (not SSD) was OK. I mistrust the external UBS-C ports on the MacBook Pro and have been more successful using a USB adapter directly on the input power cable. It seems the USB-C ports have a tendency to drop the power, or sleep, despite all settings to the contrary. Maybe the same happens even with the port to which the power is input. It is strange, though, that it only happens after a time period of several hours. Oh well. Too complicated to even start to debug.

Thanks for your efforts!
Regards,
Tim