Moving directory causes data loss

[vovcacik]

Environment

• Windows version: Windows 10 Pro
• Processor architecture: x64
• Encfs4win version: encfs version 1.10.1-RC10
• Dokan version (legacy, modern): Dokany 1.0.2

Description

Moving directory from encrypted disk to desktop results in data loss. The directory gets moved, but is empty. 100% reproducible.

Expected behavior vs. actual behavior

After moving the directory to desktop it should have all the files it had on the encrypted disk. But actually it was empty. To be precise the directory test should contain file.txt file.

Steps to reproduce problem

There is prompt to manually move the directory to desktop. You can use any of this methods:

• ctrl+x, ctrl+v
• moving the dir with mouse while holding right mouse button and selecting "Move here" from context menu upon release
• hold shift and drag & drop the dir onto desktop

To initialize encfs use standard profile (not expert nor paranoid), but it makes no difference.

@echo off
mkdir "%temp%\bug"
encfs -v "%temp%\bug" x:

mkdir x:\test
echo 1234 > x:\test\file.txt

echo Manually move x:\test folder to Desktop
pause

dokanctl /u x:
rmdir /S /Q "%temp%\bug"

Relevant logs

There is nothing interesting in the log, but anyways...

2017-02-25 19:33:49,824 VER [main.cpp:618] Forking encfs as child
2017-02-25 19:33:49,831 VER [main.cpp:696] Root directory: C:\Users\Admin\AppData\Local\Temp\bug/
2017-02-25 19:33:49,832 VER [main.cpp:697] Fuse arguments: (daemon) (fork) (threaded) (keyCheck) encfs.exe x: -f -o use_ino -o default_permissions
Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?>

Standard configuration selected.
2017-02-25 19:33:54,664 VER [SSL_Cipher.cpp:328] allocated cipher ssl/aes, keySize 24, ivlength 16
2017-02-25 19:33:54,665 VER [FileUtils.cpp:1107] Using cipher AES, key size 192, block size 1024

Configuration finished.  The filesystem to be created has
the following properties:
2017-02-25 19:33:54,666 VER [Interface.cpp:110] checking if ssl/aes(3:0:2) implements ssl/aes(3:0)
2017-02-25 19:33:54,667 VER [SSL_Cipher.cpp:328] allocated cipher ssl/aes, keySize 24, ivlength 16
Filesystem cipher: "ssl/aes", version 3:0:2
Filename encoding: "nameio/block32", version 4:0:22017-02-25 19:33:54,669 VER [Interface.cpp:110] checking if nameio/block(4:0:2) implements nameio/block32(4:0)
2017-02-25 19:33:54,670 VER [Interface.cpp:110] checking if nameio/block32(4:0:2) implements nameio/block32(4:0)

Key Size: 192 bits2017-02-25 19:33:54,671 VER [Interface.cpp:110] checking if ssl/aes(3:0:2) implements ssl/aes(3:0)
2017-02-25 19:33:54,672 VER [SSL_Cipher.cpp:328] allocated cipher ssl/aes, keySize 24, ivlength 16

Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File holes passed through to ciphertext.

Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism.  However, the password can be changed
later using encfsctl.

2017-02-25 19:33:54,679 VER [openssl.cpp:47] Allocating 41 locks for OpenSSL
2017-02-25 19:33:54,681 VER [FileUtils.cpp:1165] useStdin: 0
New Encfs Password:
Verify Encfs Password:
2017-02-25 19:33:58,031 VER [Interface.cpp:110] checking if ssl/aes(3:0:2) implements ssl/aes(3:0)
2017-02-25 19:33:58,033 VER [SSL_Cipher.cpp:328] allocated cipher ssl/aes, keySize 24, ivlength 16
2017-02-25 19:33:58,646 VER [Interface.cpp:110] checking if nameio/block(4:0:2) implements nameio/block32(4:0)
2017-02-25 19:33:58,648 VER [Interface.cpp:110] checking if nameio/block32(4:0:2) implements nameio/block32(4:0)

[vovcacik]

There is a hint. Before you run the steps to reproduce the problem create empty %userprofile%\Desktop\test directory. When you are prompt to move the x:\test directory select to merge the conflicts. Explorer will be complaining about that the file.txt is missing - this indicates that the contents of the directory is deleted before explorer has the chance to copy it.

[Rondom]

(This is a blind guess) Can you try an experimental Dokan version to see if it fixes your issue?https://ci.appveyor.com/project/Rondom/dokany/build/1.0.1-272/job/ltjus6uh1jdhq8al/artifacts

Snapshots are not signed by certificate trusted by Microsoft, so you would need to follow the instructions here: https://github.com/dokan-dev/dokany/wiki/Build#user-snapshot

Actually, the patch is inside the user-mode DLL, so if it is too much a hassle for you, just replacing the DLLs would be enough. This requires someone extracting the DLLs from that installer or compiling the (lib)dokanfuse1.dll from that commit.

[vovcacik]

@Rondom I've replaced the libs from the build you linked, rebooted and rerun the reproduce steps, but it made no difference.

  File: libdokanfuse1.dll
   MD5: c7d09fc138aa2b093df8ed020f1b6d8a
  File: dokanfuse1.dll
   MD5: 69a4343c5bb704a735d1e316b5ba997a

[Rondom]

Ok, thanks. Worth a try nonetheless :-/

[jetwhiz]

Hi @vovcacik -- this is likely an issue related to #72 (the hidden/system desktop.ini file causes lots of issues with moving/deleting/renaming on Windows).

Can you try to close the folder in Explorer, unmount the encfs drive and then remount and move the folder via command line (without re-opening in Explorer) to see what happens?

[vovcacik]

This works robocopy x:\test c:\Users\Admin\Desktop /MOVE regardless I open the encfs drive in Explorer or not.

[jetwhiz]

This problem originates from Dokany 1.0.2, but appears to be fixed as of Dokany 1.0.3.

If the most recent release (v1.10.1-RC12) doesn't fix this for you, please let me know!

[vovcacik]

Works fine with encfs v1.10.1-RC12 and Dokany v1.0.3. Thanks

[jetwhiz]

Great, thanks for the update @vovcacik !