-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Folder as mount point (in Windows platform) #22
Comments
It would be possible to support using an empty folder as a mount point. Dokany supports this. I think it would require mostly user interface changes. |
It's working. There is one limitation though. I currently can't allow mounting reverse-mode filesystems to an empty folder. They have to be mounted to a drive letter. Only forward (normal) mode filesystems can be mounted to a an empty folder. The reason is that when you mount a filesystem to an empty folder, the filenames get converted to all uppercase most of the time. I've debugged this some, and it appears that it is being done upstream of Dokany. I don't know why this happens. Reverse mode does not work in case-insensitive mode because the file names would all be lost if whatever was archiving the encrypted files didn't preserve the case of the file names. If the case of the encrypted file names is changed, then they'll base64 decode to gibberish instead of to the encrypted filename data. Is this limitation a problem for you? I plan to make a new release in the next couple of days anyway, but I'd like to know if you or anyone else is unhappy with this limitation. I could continue debugging and see if there is a solution. |
cppcryptfs 1.4.0.10 has been released https://github.com/bailey27/cppcryptfs/releases/tag/1.4.0.10 It allows mounting filesystems to empty NTFS folders in forward (normal) mode. |
I found a description of this problem: Direct mode - this is more than enough. I think few people use the reversible mode. PS Sorry for my English. |
I want to point out that currently the empty folder mount point must be added in the UI (by right-clicking on the list of drive letters on the mount tab and doing "Add Mount Point") before it can be used, even if you are mounting using the command line. In other words, I noticed that mounting using the command line fails unless that mount point has already been added in the UI. I'll fix this soon. |
All work, thanks! I install Dokan Library 1.1.0.2000 (x64). OLD BAD REPORT: OS: Windows 7 x64. Crash immediately when mounting - because i using incorrect Dokan version! Folder "D:\heXor\Crypted" contain 2 file: gocryptfs.conf, gocryptfs.diriv. Cmd "dir":
|
Thanks for reporting this. The Windows dynamic linker complains with an error dialog if you run old cppcryptfs (1.4.0.7 or before) with new dokany (1.10.x) and refuses to let it run, but it doesn't complain if you run new cppcryptfs with old dokany (1.0.x), and cppcryptfs crashes like you saw. I'll put a in check for the Dokany version to make sure it's 1.10 or greater. |
The 1.4.0.11 has been released. It doesn't require the mount point folder to be pre-configured in the ui if you're mounting from the command line. It also checks the Dokany version to make sure it's compatible. |
If find a solution to mounting a reverse volume to an empty folder that would be great. See referenced issue with gocryptfs. Thanks for your work on cppcryptfs. First looked at when more than just binary and Dokany driver was required. |
The reason for not supporting mounting reverse mode filesystems to an empty folder is purely a Windows issue. It isn't related to AES-SIV mode. |
Huge proponent of keeping code simple but originally thought a better option/ solution might be a "Syncthing" command line option on gocryptfs side to add a ".stfolder" to a read-only reverse volume. Hence the reference but have since changed mind. |
The restriction on using an empty NTFS directory as a mount point in reverse mode has been removed in cppcryptfs 1.4.0.19 |
It's possible?
encfs4win can do it. (command: "encfs.exe d:\Data_Crypt\ d:\Data")
The text was updated successfully, but these errors were encountered: