QRecall

Chris Petit

Note to others that want to use encryption. You should use lion's volume encryption feature and not an encrypted disk image or sparse bundle.

The sparse bundle creates two disk directory indexes, which can cause problems.

James says he will also be adding encryption directly to the program in a future version so be on the lookout for that as an option.

Adam Horne

Is this possible on a RAID volume?

Yesterday, I had a friend who's home was broken into. He had a set up similar to mine (2 RAID HD) sitting on his desk that were stolen. Fortunately, he had an encrypted spares bundle for his personal documents.

I'm wondering if I can do the whole volume and more or less use the drive like normal. But once it's unplugged, the data is protected until the password is entered.

Any thoughts?

James Bucanek

Adam Horne wrote:Is this possible on a RAID volume?

It should be. HFS+ encryption is performed at the filesystem plug-in level (that controls how files are organized on a device), while RAID works at the device driver level (that does the work of reading and writing data blocks to hardware).

In Disk Utility, select a volume on your RAID and go to the Erase tab. If one of the choices is Mac OS Extended (Journaled, Encrypted), then you can create an encrypted volume on your RAID.

Adam Horne

So I transferred my files off of the drive to another HD. I formatted the drive as Mac OS Extended (Journaled, Encrypted) and brought the files back over, including my qrecall archive.

Now I'm getting an error from the Qrecall log:

"Failed: cannot convert FSRef to path"
"Error: no such volume"
"OSErrName: nsvErr"
"OSErr: -35"

I've updated all the actions to the new path of the archive and the "captured item" and still no luck.

James Bucanek

Adam Horne wrote:Now I'm getting an error from the Qrecall log:

I'd be interested to know where in the log this message occurs. Rather than playing "20 questions" I'll ask that you send a diagnostic report (Help > Send Report...) and we'll work from there.

James Bucanek

Adam,

The error you're getting is, I believe, a bug in Mountain Lion's implementation of FSCopyObj, the core library function that copies files. It's not "technically" a bug, because Apple has deprecated the core library file services API in Mountain Lion, which means that they are no longer maintaining or supporting those functions.

The problem is that after FSCopyObj has duplicated a file, it supposed to return a reference to the new (duplicate) file. On your new volume, that reference is invalid for some reason and QRecall can't open the file it just duplicated. (This is not a new bug; both Leopard and AppleShare file servers, which include airport base stations, have a similar bug.)

Many moons ago I cobbled together a workaround that duplicates the file using other means. If you're interested in trying that code, let me know and I'll build a special version of QRecall 1.2.1 that doesn't use FSCopyObj.

I'm in the process of rewriting all of the low-level file functions to use the (ancient, but now official) BSD API for all filesystem services. If all goes well, a beta that uses the new filesystem APIs will be available for testing soon.

Adam Horne

James Bucanek wrote:Adam,

The error you're getting is, I believe, a bug in Mountain Lion's implementation of FSCopyObj, the core library function that copies files. It's not "technically" a bug, because Apple has deprecated the core library file services API in Mountain Lion, which means that they are no longer maintaining or supporting those functions.

The problem is that after FSCopyObj has duplicated a file, it supposed to return a reference to the new (duplicate) file. On your new volume, that reference is invalid for some reason and QRecall can't open the file it just duplicated. (This is not a new bug; both Leopard and AppleShare file servers, which include airport base stations, have a similar bug.)

Many moons ago I cobbled together a workaround that duplicates the file using other means. If you're interested in trying that code, let me know and I'll build a special version of QRecall 1.2.1 that doesn't use FSCopyObj.

I'm in the process of rewriting all of the low-level file functions to use the (ancient, but now official) BSD API for all filesystem services. If all goes well, a beta that uses the new filesystem APIs will be available for testing soon.

Any idea when the beta will be ready? In the meantime, i'll use other applications for backups, but I sure do miss QRecall...

James Bucanek

Adam Horne wrote:Any idea when the beta will be ready?

No firm date yet. I was hoping by the end of September, but that ship has already sailed. It turns out that there's a lot of low level file access code to replace.

Ralph Strauch

My experience using whole disk encryption for archives has been positive. I maintain a pair of archive drives, backupA and backupB, both of which are encrypted using Mt. Lion's whole disk encryption. I keep one offsite and backup to the other, switching them every week or two. It works fine. When I first mounted each drive I had to enter the password, but it's now stored in my keychain so I don't even have to do that. I keep the backup drive mounted on one computer, and backup a second computer to the same archive over wifi. Once the drive is mounted and the password has been entered, both computers access it transparently.

When I first set up this system I thought about giving both archives the same name and having only one action to back up to both, since only one would ever be attached to the computer. I asked James about that and he advised against it, saying the OS would recognize the drives as different and refuse to back up to one of them, even if they had the same name. I then set up separate actions for each drive, keeping one of those actions "suspended" and switching that at the same time I switch drives. Works great.

Ralph

Peter B.

Chris Petit wrote:Note to others that want to use encryption. You should use lion's volume encryption feature and not an encrypted disk image or sparse bundle.

The sparse bundle creates two disk directory indexes, which can cause problems.

James says he will also be adding encryption directly to the program in a future version so be on the lookout for that as an option.

Does this refer to encryption for the QRecall archive (putting the QRecall archive on an encrypted volume or encrypted sparse bundle), or to the data that will be backed up on the QRecall archive (backing up an encrypted volume or encrypted sparse bundle)? I think that it's the former, but I'd like to be sure.

James Bucanek

Peter B. wrote:Does this refer to encryption for the QRecall archive (putting the QRecall archive on an encrypted volume or encrypted sparse bundle), or to the data that will be backed up on the QRecall archive (backing up an encrypted volume or encrypted sparse bundle)? I think that it's the former, but I'd like to be sure.

It's the former.

You can encrypt a QRecall archive now by storing it on an encrypted volume or in an encrypted disk image.

Since this isn't always practical, or convenient, there's a plan to add record-level encryption to the archive. (Tip: turning on compression for the archive will also obscure any sensitive data from all but the most determined hackers.)

Peter B.

Ah, thanks!