request: mount to subfolder inside new drive letter

[Owyn]

Description

For cloud-backup scenario using drive letter mount-point is currently impossible because most cloud programs create some kind of database files or other settings in files in root folder, but with --reverse mounted to drive letter it is impossible for cloud programs to write files there, and alternative to mount to folder brings some issues

can anything be done without much effort?

Like Z:\ drive would redirect all file\folder requests to some folder (folder one level above selected as source?), and "Z:\out" would work as Z:\ in current version (encrypted files would be put there, can this be done?

[jetwhiz]

Hi @Owyn -- I'm not sure I completely understand the issue and proposed fix. Does mounting your encfs directory to Z: and then making a directory junction between Z: and C:...\Dropbox not work?

I'm not sure if the issues described in #51 apply in this situation, but I've successfully used this setup in the past.

[Owyn]

It works, but it doesn't let anything to be written into Z: by design (cuz --reverse is used), an I need cloud sync app to be able to write there or else it wouldn't work.

[jetwhiz]

You're right, for my setup I usually do not use reverse mode. For reverse mode I think you should be able to mount to a folder, which should solve this issue? Are you experiencing problems when mounting to a folder in reverse mode (using Block32 filename encoding)?

[Owyn]

You're right, I'm using the folder mounting currently, but I think because it's considered a junctions no file update information is passed like it usually is in standart folders so sync app can't pick up filechange-events unless you restart it, I thought maybe mounting to drive letter would work like a full-packed filesystem, I'm not using filename encoding due to length issues

[jetwhiz]

I'm not familiar with what you need for your setup, but could you keep C:\...\Dropbox as your encrypted folder and then just mount (not in reverse mode) to Z: for access to the decrypted files?

The issue you're experiencing with file changes not being picked up is likely because your cloud sync is attached to the folder, so when you replace the folder with a directory junction the cloud sync software is not aware that it has been changed (so you must restart it).

[Owyn]

I'm not familiar with what you need for your setup, but could you keep C:...\Dropbox as your encrypted folder and then just mount (not in reverse mode) to Z: for access to the decrypted files?

Yes, I could do that I suppose, but I highly prefer -reverse mode to keep original files on my drive

[ephestione]

Pitching in, as I just installed encfs4win especially for this purpose (and earler I noticed Owyn's feedback on EncFSMP boards asking for --reverse there).
So, at the current point, is it not possible to achieve what we would like? To have a working setup where Dropbox correctly works on a --reverse mounted subfolder inside the Dropbox path?

[jetwhiz]

@Owyn @ephestione

I've cherry picked a commit from upstream that allows for writing in --reverse mode (as long as uniqueIV is disabled). Would this be enough to solve this issue for your usage?

[Owyn]

Well, encrypting on the fly those database files would just waste resources but it would make the whole mechanism work I suppose.

But then it would also make all other files allowed for writing and easy to mess up or just delete by the cloud program which likely to happen in unusual use cases (like encryption on the fly). I wish there was a simple read-only flag for subfolders or smth like that.

[ephestione]

I have just basic understanding of the matter if compared to what Owyn clearly shows, so I will trust anything that you two decide

[Owyn]

Z:\ drive would redirect all file\folder requests to some folder (folder one level above selected as source?), and "Z:\out" would work as Z:\ in current version (encrypted files would be put there, can this be done?

so, suggested behavior: if non-existing drive letter is specified along with subfolder, example "Z:\out":
it would mount to "out" folder and all file operations outside of it (in Z:\ root and other subfolders if created) would be redirected raw to folder named "encfs_root_files" near to folder picked as source

That would be the perfect solution, I hope that won't be too complex or bloated to implement and would suit cloud scenario perfectly

if encfs could use ntfs file permissions of source files all above wouldn't be needed btw, and just a writable reverse would suffice - maybe that could be done as an alternative solution?

[jetwhiz]

I think any changes that big would need to happen upstream, since I don't want to deviate that far from what encfs is doing. This is mainly just intended to be a Windows fork of encfs, and those changes would apply across-platform.

From what I can tell, the normal, underlying ntfs file permissions should already carry over to the reverse-mode folder.

[Owyn]

Could you check NTFS permissions? On my side, reinstalled new encfs a minute ago, no permissions are there

[jetwhiz]

Oh I was referring to the readonly flag, not the full-blown ACL for Windows. That would be a much bigger effort to implement.

[Owyn]

well, if you are going to make -reverse writable in the end at least add a flag to toggle it, that would be nice.

Though
#65
read-only thing of -reverse doesn't work anyway as mentioned in that issue...

[Owyn]

btw, if -reverse would become writable how would it work anyway? what would happen if you go and write an unencrypted file (cloud database file which is being worked on all the time) into encrypted output destination (e.g. Z:\ drive), will it stay unencrypted in encrypted output folder after drive remounting of our -reverse? hard to imagine...

[jetwhiz]

For reverse mode you would write encrypted files into it, and they would come out decrypted on the other side.

[Owyn]

Then that would be useless for the sake of this threads issue - cloud programs subsidiary files

[jetwhiz]

With the null filename cipher it will work the way you want it to, but the cloud program's files will be encrypted and stored alongside your original/unencrypted files (since encfs will "decrypt" the plaintext files from the cloud provider).

If you're hard-set on having the cloud provider's files stored one level up then I would recommend putting in a feature request on the upstream encfs project (since this change is not specific to Windows). After it is implemented there then we can pull that functionality into this Windows fork.

[benrubson]

well, if you are going to make -reverse writable in the end at least add a flag to toggle it, that would be nice.

Reverse writable mode is available in last upstream version, with --reversewrite 👍

[ephestione]

well, if you are going to make -reverse writable in the end at least add a flag to toggle it, that would be nice.

Reverse writable mode is available in last upstream version, with --reversewrite 👍

I tried --reversewrite on encfs4win but it's not yet supported.

The status as of the latest version, is that I can mount with reverse like this:
encfs.exe --reverse --extpass="cmd /c echo password" "unencrypted source folder" "encrypted target folder"
but the command, which is inside a batch script, after executing and creating the target filesystem inside Dropbox tree, outputs a couple of warnings about mounting to a folder instead of a drive letter, and freezes, preventing the batch script from continuing with the second encfs mount command.

Dropbox, in the meantime, starts processing the mounted folder but doesn't ever upload anything, and after a while appends a "X" red icon on the folder, meaning there are some problems, which probably is because the folder itself is not writeable.

[benrubson]

See EncFS wiki for other existing Windows solutions.

[ephestione]

I'm not familiar with what you need for your setup, but could you keep C:...\Dropbox as your encrypted folder and then just mount (not in reverse mode) to Z: for access to the decrypted files?

This is exactly what I've been doing for several years, using the mounted unencrypted folder as primary and only working folder for my local web application that manages my job... until #125 happened :'(

I think I managed to recover all files, but now for obvious reasons my hardcopy is going to be the unencrypted one and I was looking for an automatic, no-human-intervention method to sync it to Dropbox in encrypted format.

[ephestione]

See EncFS wiki for other existing Windows solutions.

I went as far as building encfs under cygwin where the integration tests failed significantly (but I thought it was normal since it's running in windows after all) but when I tried and ran encfs.exe from windows terminal it popped a lot of cygwin error dialogues.

Then I tried running the exe from cygwin unsuccesfully until I remembered it was supposed to work like a linux terminal and I finally used ./encfs.exe instead of just running encfs.exe, I did mount with --reversewrite inside the dropbox tree, but even in that case dropbox wouldn't upload no matter what, even if every file and folder inside the reverse mountpoint had the "syncing" icon overlay.

[benrubson]

I went as far as building encfs under cygwin

Thats' certainly the preferred method.

the integration tests failed significantly

See wiki for explanations.
Also see wiki for warnings, and dropbox considerations in manpage.

[jetwhiz]

Hi @ephestione

Right now we do have the latest features merged in with encfs4win already in our dev-195 branch (https://github.com/jetwhiz/encfs4win/tree/dev-195), which is planned to be our v1.11 beta. This is based on the latest upstream encfs v1.9.5

You can try it out by pulling the executables off of our v1.11.0-beta.1 beta release.

[ephestione]

I will be testing encfs when the new features get into the stable version, as of now there is still something wrong where encfs terminates the mount, even after rebuilding the folder from scratch. Now I am also using no filename encryption for ease of maintenance and to reduce problems with pathname length, so it must be definitely something between encfs4win and my system, as no corruption could possibly be in the folder since it's brand new.

[jetwhiz]

Usually immediate disconnects like that are related to the Dokany FUSE layer ... can you try the Dokany fuse_mirror sample and see if the problem exists there, too?

It is located in "C:\Program Files\Dokan\Dokan Library-1.2.2\sample\fuse_mirror", and you need Cygwin to be installed to run it. Note that the "Dokan Library-1.2.2" should be the only folder under Dokan (otherwise an old version failed to uninstall properly).

You can mount the default directory just by running mirror.exe Z:, for example.

[ephestione]

I commend you for being so extremely ready to reply to users on this forum.
I reinstalled cygwin as I had uninstalled it previously after a failed attempt at trying out the encfs from linux.
Running mirror.exe from command prompt gives all kinds of errors, running it from cygwin terminal (I wouldn't know how to script that from a startup batch tho) mounts on the specified drive letter a mirror of the cygwin root path :-| I cannot seem to bring up a legend of the mirror.exe options by using ? or /? as parameter.
I am lost 👯

[stale]

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.

[gab]

Sorry StaleBot, but this doesn't seem ripe for closing.

Has anyone managed to make --reversewrite work in encfs4win after all?

[jetwhiz]

Hi @gab

This was implemented upstream in the latest encfs, and should be in the beta version of encfs4win v1.11.0-beta.1.

Could you check to see if this functionality is working for you?

Please see the --reversewrite option in the manual for details on restrictions.