I archive to a NAS from my iMac over ethernet and mount my NAS volumes using smb, the Qrecall actions point to these archives on the NAS volume. Everything works fine normally but occasionally, for some reason that I have yet to discover, and unrelated to Qrecall, the NAS volume will mount using afp. I even have the same volume mounted with both afp and smb at times.

If I don't notice this and Qrecall tries to run a capture it will fail and I have to repair the archive. I don't understand why the network protocol should have any bearing on the capture action but it clearly does and it is annoying when I have to repair the archive, which takes several hours.

Ideally, I'd like to know why the NAS volume mounts as afp anyway and I'd like to find a way to tell the OS not to mount any volume as afp under any circumstances, but so far that has defeated me.

Any ideas James?

I can't offer any advice as to why your NAS suddenly decides to mount your volumes using AFP, but the vendor might.

I would be interested in investigating why your archive is getting corrupted and needs repair. If you can, please send a diagnostic report from the computer that is mounting the volume using AFP and trashing the archive.

Apple File Protocol (AFP) has a few known bugs, and older versions have a bunch of bugs. So it might depend on what version of AFP your NAS is running.

If you're still running QRecall 1.2, there are some advanced setting designed specifically to work around some of these bugs. QRecall 2.0 uses a different filesystem API that was supposed to put this kind of incompatibility behind us, but depending on the version of AFP there still might be issues.

The two biggest stumbling blocks in APF are a pre-allocation bug that ends up filling the volume and a file-size limitation. The pre-allocation bug can be worked around. But if it's a very old version of AFP that can't write really large files, there's nothing QRecall can do about that.

I am running OSX 10.11.5 but it has occurred in recent versions.

The NAS volume are mounted from Finder, more recently using an application called Mountain rather than the NAS mounting the volume itself.

Report on its way to you.

The errors you're getting when the volume is mounted using AFP are strange indeed. I'm not entirely sure what to make of them.

A prime example is the capture that failed today. The archive couldn't be opened because the length of the negative hash map file was reported to be -4 by the operating system. I don't think I've ever seen a negative file length.

I will also note that the volume containing the archive was not mounted when the action started, so QRecall mounted the network volume automatically. (This also appears to have caused two other volumes to mount at the same time.) All three volumes were mounted using AFP.

Because of this, I might offer the possibility that when OS X mounts the volumes they get mounted using AFP, but when your utility mounts the volume they get mounted using SMB.

James

Qrecall has never mounted the volumes automatically, I have always had to mount them manually or by an application such as Mountain. I usually have three NAS volumes mounted, one of which is used for Qrecall.

It was just coincidence then. The timing (action started running at 10:03:37 and the volume mounted at 10:03:40) made it look like the volume had been automatically mounted by QRecall.