Support for symbolic links

[JackSabbath]

As far as I remember the old EncFS4Win had some serious bugs when the mounted folder was used with symbolic link. I don't remember what I did exactly then ago, but I know that I lost some files to it.

What I wanted to ask is:

1. How well does the current version deal with it?
2. Are symbolic links taken into test scenarios?
3. In case there's still no support: is it planned?

[jetwhiz]

@JackSabbath -- are you referring to using symbolic links inside of your encrypted container, or pointing to the encrypted container with a symbolic link?

Right now, the underlying FUSE software that we use (Dokany) does not support symbolic links, so it is not possible to use symbolic links within the encrypted container in encfs4win. I have put in a feature request with Dokany to add this functionality.

[JackSabbath]

@jetwhiz I don't really know what I did. It is more likely that I set a symbolic link pointing to the encrypted container. And IMO this is a feature that EncFS4Win should have for sure, since symbolic links are often the only way to add an external folder to your cloud sync folder. For example if your Dropbox lies in C:\MyDropbox and your encrypted photos are in D:\EncryptedPhotos, then you're stuck with symbolic links.

But back to the general situation: There are eight ways how symbolic links could be used with EncFS4Win:

1) A symlink is pointing to the root of the Encrypted folder:

• The user wants the encrypted folder to be virtually at more than one location. See the top discussion.

2) A symlink is pointing to a subfolder of the Encrypted folder:

• The user wants a part of the Encrypted things somewhere else.. might be useful for syncing Encrypted photos on Dropbox and Encrypted Documents on Google Drive.
• The user should better create two seperate Encrypted folders in this case, since partial usage means that a single subfolder might be useless without the rest of the Encrypted folder.

3) A symlink is pointing to the root of the UNencrypted folder:

• The user wants his important data to be at a certain location. For example D:\SomeProject\src

4) A symlink is pointing to a subfolder of the UNencrypted folder.

• Also trivial. The user wants his some of his important data to be at a certain location.

5) The symlink IS the root of the Encrypted folder and points to another location.

• The user wants his Encryption to be virtually at a certain location, while it is physically stored somewhere else.
• I have no idea if this is a use scenaio that should be considered, since this achieves pretty much the same as case 1). However, a user still might just do this.

6) A symlink is inside the Encrypted folder and points to another location.

• Now it starts to get tricky. The user probably wants to store the Encrypted data across several physical drives, while syncing it into one cloud.
• The user should better create two seperate Encrypted folders in this case, since the Encrypted folder is pretty much governed by EncFS4Win and changing the physical location of subfolders breaks this government.

7) The symlink IS the root of the UNencrypted folder and points somewhere else.

• I don't think the OS would allow this, since it would require the UNencrypted folder to be created two times: by the symlink and by dokany. Whatever the user is doing, he is doing it wrongly.

8) The symlink is inside the UNencrypted folder and points to another location.

• To me it is unclear what a user, who does this, would expect:
• Case A: The user might want to tell EncFS4Win, that the linked data shall also be encrypted, since he creates a virtual copy inside the folder, that shall be encrypted. This would bring problems for sure, because even if the desired encryption happens - the Encrypted folder wouldn't store the symlink itself, meaning that the link to other data will decay to a copy of those data on the next mounting, which is surely not what the user intended, since he chose to create a symlink instead of a copy. Also, on Windows, EncFS4Win won't be notified if the content of a linked folder changes, since Windows notifies only the original instance of a folder.
• Case B: The user might want the symlink itself to be encrypted. The linked data won't be encrypted, but the link-up will be restored on the next mount.
• Even though case A would be the correct behaviour (by definition the symlink shall behave as it would be the linked data), case B makes IMO more sense to implement, because case A provokes unexpected behaviour.
• I suggest showing a little dialog to the user when EncFS4Win notices, that the user created such a symlink, to tell him what will actually happen and how he might achieve the other case.

So, one case should be impossible to create, six of them are pretty straight forward (in case that Dokany will be able to handle symlinks in the future) and only case 8 needs special care.

[jetwhiz]

Thanks for the great summary, @JackSabbath ! Here is an update on what I can tell you right now for each case based on some tests I've run:

1, 2 and 5 - This will not work currently due to the same reason that encfs must be mounted to a drive letter. See this issue for details (https://github.com/dokan-dev/dokany/issues/293). However, symbolic links pointing to files should work fine (since they do not use reparse points).

In summation, Windows/Dokany returns filenames/paths that are all uppercase when reparse points are used. Since filenames in encfs are encrypted, and "myfile.txt" encrypts completely differently than "MYFILE.TXT", this breaks encfs.

We are still investigating why this uppercase conversion happens. (Note that symbolic link directories are treated as directory junctions as long as they are local, so the same problem affects directory junctions).

3 and 4 - This should already work, since the unencrypted folder should be unaffected by encfs.

6 - This will not work currently because Dokany does not support symbolic links (see https://github.com/dokan-dev/dokany/issues/343).

7 - I don't think this is possible, since the mount location already exists in that case.

8 - This should work fine, since it is transparent to the encfs program.

[JackSabbath]

I'm a bit surprised by the outcome of this. I thought Dokany is used to create the virtual drive (which represents the decrypted data), so in this case Dokany wouldn't know anything about the Encrypted folder. Please correct me if I'm mistaken, but isn't the Encrypted folder lying on some (already existing) disk and is only accessed by EncFS4Win?

The fact that confuses me is: if Dokany doesn't know about Encrypted folder, how can Dokany be the reason that the Encrypted folder can't be accessed by a symbolic link, like in case 1? I would expect that case 8 would be a problem for Dokany.

Maybe we are using different Terminology. I meant: Encrypted folder = the folder that stores the encrypted files, which might be synced into some cloud. UNencrypted folder = the virtual drive that shows the decrypted (original) data.

[jetwhiz]

@JackSabbath -- yes I was using the opposite terminology (Encrypted -> becoming encrypted, unencrypted -> becoming decrypted) ... you can swap encrypted/unencrypted for the above cases that I wrote.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.