QRecall Community Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 

Backup of encrypted file-system folder fails (Boxcryptor Classic) RSS feed
Forum Index » Problems and Bugs
Author Message
Hanno Kaiser


Joined: Sep 5, 2009
Messages: 6
Offline
I use a folder with an encrypted filesystem within Dropbox. Once the password is entered, the folder is mounted as a volume ("Boxcryptpor") and can be accessed via the Finder. (The encryption/mounting is done by a utility named Boxcryptor Classic, which builds on EncFS. See: www.boxcryptor.com)

First, I tried to back up the Boxcryptor volume with QRecall, but QRecall doesn't see it (i.e., I can't select it).

I then tried to back up the volume as a folder, but that results in a 1K backup of the symlink (or alias) that points to the decrypted volume.

To be clear, I can back up the *encrypted* files, but what I'm looking for is a backup of the *decrypted* files after the Boxcryptor folder has been mounted. Any suggestions would be much appreciated.

Best,
HK
James Bucanek


Joined: Feb 14, 2007
Messages: 1572
Offline
Hanno,

I downloaded and tested Boxcryptor Classic on a MacPro (10.8.5). Here's what I found.

The Boxcryptor system creates a bundle (Boxcryptor.bc) in your Dropbox/cloud/whatever folder. The package contains the encrypted versions of your files. As you already know, QRecall can capture these just fine.

The Boxcryptor Classic app creates a virtual files system that mirrors those files in an decrypted form. The problem is that the volume doesn't behave like a regular volume.

When I captured the volume, QRecall immediately reports that the volume fails to report its extended attributes (listxattr() returned error 2, which is "no such file or directory"). This pattern gets repeated when QRecall attempts to capture individual files in the volume (file not found and folder not found).

If I had to guess, I'd say that Boxcryptor's implementation of their filesystem fails to support extended attributes and/or the fsIDs used by the Carbon filesystem API to identify objects on a volume. That could explain why QRecall's attempt to open a file or folder return "not found". The next version of QRecall might have better luck, as we're switching to the BSD filesystem API, which tend to be friendlier with foreign filesystems.

- QRecall Development -
[Email]
Hanno Kaiser


Joined: Sep 5, 2009
Messages: 6
Offline
James:

1. Thank you for your response and for taking the time to replicate the problem! It is much appreciated. Some further digging confirmed your conclusion that the EncFS filesystem, which is accessed via OSXFUSE, does not support extended attributes. In addition, EncFS is case sensitive, which my normal volumes are not.

2. As a workaround I now maintain a copy of the unencrypted files in a regular folder that mirrors the contents of the Boxcryptor folder. A script updates the copy just before the scheduled QRecall backup.

Best,
HK
 
Forum Index » Problems and Bugs
Go to:   
Mobile view
Powered by JForum 2.8.2 © 2022 JForum Team • Maintained by Andowson Chang and Ulf Dittmer