I have an external (i.e. network-connected) RAID box running ubuntu. The drives are ext3 and I want to back up my OS X boxes to it. I'm able to drag-and-drop files to the box (yay Samba ) but want to know if QRecall can automate the process, to include maintaining permissions, etc. Will it be able to help? Rsync always seems to give me errors so I'd like to find something more reliable.

It sounds like you want to create a QRecall archive on the Linux server that's connected to OS X via Samba.

If that's the case, it should work. QRecall is designed to capture from HFS+ volumes, but it can write an archive to just about any filesystem (MSDOS, Samba, UFS, ...). The archive itself is just a package (directory) that contains a set of flat files. The principle prerequisite is that the filesystem that contains the archive be able to efficiently, and correctly, handle large (multi-Gigabyte) data files.

So everything captured from your OS X volume (file data, metadata, ACLs, and so on) ultimately just become data in a flat file in the archive package.

Thanks! I'll give it a shot tonight and see how it goes.

James - No love. I know this isn't a support issue (and so shouldn't be on this board) but I'd like to email you the log and see what you think might be the problem. Would that be OK?

If you're using the release version, the log files are in ~/Library/Logs/QRecall. If you are using the beta, just choose Help > Send Report...

Thanks for sending me your log files.

The problem is a curious one. During the process of duplicating files inside the archive, QRecall encounters error -54, which is a generic "permissions error."

The oddity is this: at the point where the error occurs, QRecall has already created an written a number of other files successfully, so to suddenly get a "permissions error" seems inconsistent. Then again, it might be a peculiarity of the FSCopyObjectSync function (which is the call that's failing).

Here are two things to try that might help us narrow the problem.

1) Try NOT pre-authorizing QRecall to run with administrative privileges. It's possible that Samba or FSCopyObjectSync is becoming confused when the processes switches UIDs.

2) Try the release version of QRecall (version 1.0.1). Version 1.0 doesn't use the FSCopyObjectSync function. To install the release version (or any earlier version), first uninstall the current version by holding down the Shift+Option keys and choosing QRecall > Quit and Uninstall. Replace it with the older version and start it up again.

Looks like it worked. I told it to do just grab my profile files and it chugged along and reports that the 36g+ worth of the files transfered to the file server. I'm having it verify the archive now. It looks like whatever the difference between the versions is is what caused the problems. Will that be an issue when the new version is released?

It will most likely be a problem with the next release, as a number of new features depend on FSCopyObjectSync.

However, there are potentially a number of solutions. Let me first investigate why FSCopyObjectSync is a problem on Samba shares and then look for a workaround.

OK. Thanks for the reply. Looks like I'm going to have to hold off on a purchase until then.

Also, what is QRecallMonitor? I've killed the process multiple times but it keeps respawning. Is there a way to shut it down? I'm not sure if it's tied to the scheduler, but I don't have a desire to monitor du changes or schedule an automatic backup, etc.

ubrgeek wrote:Also, what is QRecallMonitor?

QRecallMonitor is a background (dockless) application who's primary purpose is to present the floating QRecall Activity window that shows the progress of running actions.

I've killed the process multiple times but it keeps respawning.

QRecallMonitor is installed as a launchd user agent. If you kill it, launchd just starts it again.

Is there a way to shut it down?

Not really, except by uninstalling QRecall or logging out.

I'm not sure if it's tied to the scheduler, but I don't have a desire to monitor du changes or schedule an automatic backup, etc.

It isn't tied to the scheduler, per se. It displays the status of the scheduler, scheduled actions, and the progress of independent actions started by the application. It also performs a number of useful tasks while you are logged in. Among other things, it monitors disk mount/unmount events and maintains the capture history information used by the QRecall contextual pop-up menu.

Gotcha! Makes sense.

Thanks James. Looking forward to see if you're able to fix the silliness on my side. Would love to be able to use QRecall as it's the easiest and best solution I've found

ubrgeek,

One of the Apple network engineers thinks that the problem might be protocol interop issue. Would it be possible to capture a packet trace between the two machines during a capture? (I would suggest preforming a very small capture on a new archive, or else the trace will be huge.)

The Apple engineers think that the problem is in the file access mode translation.

Some archive files are opened by several threads simultaniously. When a file is open by multiple processes, the access modes all have to be in harmony. When the access modes are translated into HFS or AFP access modes, QRecall is happy. But when the access modes are translated into SMB access modes, they apparently collide.

QRecall version 1.1.0(27) opens its index files using more restrictive access modes. Hopefully, these will translate into equally compatible SMB access modes.

If you want to try this again, download 1.1.0(27) and give it a try.

Thanks. I grabbed a copy and the beta serial key and will test tonight and report what I find.