encfs stays open and doesn't return to command prompt after mount command

[ephestione]

Sorry to be opening several issues, but I don't see this reported elsewhere. After #125 and after realizing --reverse cannot be used with Dropbox, I found an ugly and inefficient method of having a clear master copy and only sending encrypted data to the cloud: I keep the working folder on my disk normally, then create an encrypted folder inside dropbox and mount it on another folder (don't want to be creating new drive letters around) to where I ROBOCOPY the master copy each N minutes. The following happens.

Environment

• Windows version: 10
• Processor architecture: i7
• Encfs4win version: latest at timeof writing
• Dokan version (legacy, modern): modern

Description

C:\WINDOWS\system32>"c:\Program Files (x86)\encfs\encfs.exe" --extpass="cmd /c echo password" C:\Dropbox\encfs C:\encfs -v -o -d
2019-05-02 10:03:29,909 WARN  [default] Caution: Mount directly to a drive letter (e.g., X:) to prevent file/folder not found issues!
2019-05-02 10:03:29,924 VER [main.cpp:619] Forking encfs as child

2019-05-02 10:03:29,956 WARN  [default] Caution: Mount directly to a drive letter (e.g., X:) to prevent file/folder not found issues!
2019-05-02 10:03:29,956 VER [main.cpp:697] Root directory: C:\Dropbox\encfs/
2019-05-02 10:03:29,956 VER [main.cpp:698] Fuse arguments: (daemon) (fork) (threaded) (keyCheck) encfs.exe C:\encfs -o -d -f -o use_ino -o default_permissions
2019-05-02 10:03:30,210 VER [FileUtils.cpp:296] found new serialization format
2019-05-02 10:03:30,210 VER [FileUtils.cpp:310] subVersion = 20100713
2019-05-02 10:03:30,210 VER [Interface.cpp:110] checking if ssl/aes(3:0:2) implements ssl/aes(3:0)
2019-05-02 10:03:30,210 VER [SSL_Cipher.cpp:328] allocated cipher ssl/aes, keySize 24, ivlength 16
2019-05-02 10:03:30,241 VER [Interface.cpp:110] checking if ssl/aes(3:0:2) implements ssl/aes(3:0)
2019-05-02 10:03:30,241 VER [SSL_Cipher.cpp:328] allocated cipher ssl/aes, keySize 24, ivlength 16
2019-05-02 10:03:31,009 VER [FileUtils.cpp:1622] cipher key size = 44
2019-05-02 10:03:31,009 VER [Interface.cpp:110] checking if nameio/block(4:0:2) implements nameio/null(1:0)
2019-05-02 10:03:31,009 VER [Interface.cpp:110] checking if nameio/block32(4:0:2) implements nameio/null(1:0)
2019-05-02 10:03:31,009 VER [Interface.cpp:110] checking if nameio/null(1:0:0) implements nameio/null(1:0)

After this the command prompt window stays open because encfs keeps it "locked". After a while I am able to use Ctrl-C (not right away because it won't register) and it goes like

2019-05-02 10:14:07,557 VER [main.cpp:969] ConsoleHandler: Nothing to do!
Terminate batch job (Y/N)?

I enter y and the command prompt window finally closes, but the mount is still operational.

Expected behavior vs. actual behavior

encfs mounts to the folder even after the warning, then releases the command prompt so the window closes. Instead, command prompt is not "released" and window stays open indefinitely.

Steps to reproduce problem

Not sure, maybe mount to a folder instead of a drive letter?

Relevant logs

(as per in the description)

[ephestione]

Nevermind, it's a no go anyway. Something on my system must be preventing encfs4win from working correctly. I finally capsized and resolved to mount to a drive letter, so that the mount command did return to command prompt and released the window which closed correctly. BUT. As soon as I start the robocopy command, the virtual drive unmounts, just like https://github.com/jetwhiz/encfs4win/issues/62#issuecomment-328475181 in #62

I have to revert to EncFSMP even if I don't like one bit its closed source components.

[jetwhiz]

Hi @ephestione

This is a known issue with mounting to folders instead of drive letters due to case insensitivity with Windows paths and filenames. We recommend mounting to a drive letter instead in order to prevent this issue.

[ephestione]

Yes, I am still using the -ugly- method reported in my previous comment in this thread :(

[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.