search

jetwhiz / encfs4win

Windows port of EncFS
https://encfs.win
Other
400 stars 41 forks source link

Can not use encfs mounted drive or directory with go applications (e.g rclone) #71

Closed qnorsten closed 7 years ago

qnorsten commented 7 years ago

Environment

Description

Hi, I am not sure if this is a encfs4win or DOKAN error, but will try to post here first

If I do a mount with encfs (both regulary or--reverse) and then try to copy either the whole mounted drive or a directory with rclone it will fail (exactly as described here https://github.com/ncw/rclone/issues/261), while I can still copy individual files perfectly. If I use a linux VM to upload with rclone it works perfectly. According to the referenced issue it is not a rclone issue but either encfs4win or DOKAN.

Error message: Local file system at \?\X:\: Failed to open directory: \?\X:\: Readdir \?\X:\: The system cannot find the path specified.

Expected behavior vs. actual behavior

I expect the mounted folder or drive to be accesable and able to sync with rclone

Steps to reproduce problem

  1. Mount somefolder, regulary or with --reverse encfs --reverse X:
  2. Try to copy the drive or a directory with rclone rclone copy X: Remote:FolderonRemote rclone copy X:/somedirectory Remote:Folderonremote

Relevant logs

Not sure what logs can be relevant, but if anyone is needed let me know (does encfs4win save log-files anywhere?)

Attach any relevant log files that can help to debug your issue (be sure to use the -v option for verbose logs).

jetwhiz commented 7 years ago

Hi @qnorsten -- thank you for the report.

What command are you using exactly to perform this? If you're using "encfs.exe --reverse C:\orig X:", then X: might be read-only. In this configuration you should be writing plaintext data to the C:\orig folder (and X: will be the encrypted ciphertext output). Attempts to write to X: will probably fail (see the encfs documentation here: https://github.com/vgough/encfs/blob/master/encfs/encfs.pod)

If that isn't the case, then can you test this out with the Dokany mirror sample and see if the issue exists there as well? It is typically located at: "C:\Program Files\Dokan\Dokan Library-1.0.1\sample\mirror\mirror.exe"

You can mount a folder on your computer with the command (writing to Z): 

mirror.exe /r C:\mount\this\folder /l Z:
qnorsten commented 7 years ago

Thanks for the respone. I see now that the markup screwed up my previous comment, so I have updated it so the remote part of the rclone commando is shown. (I tried to use '<' with it before that seems to be filtered away)

I am not trying to write to Z just copy it with rclone to a cloud (google drive) that I setup in rclode as Remote.

I just tried to mount both an unencrypted and an encrypted folder with mirror and transfered the files it and it worked perfectly. I can also transfer encfs encrypted files directly from one of my local hardrives.

If I mount with encfs to Z : and try to transfer files and directories from this mount point I can transfer specific files such as test.txt by using rclone copy Z:/test.txt Remote:Test (Test is just a folder on the remote) While if I try to transfer the whole mounted virtual drive or a directory with rclone copy Z Remote:Test I get the previously mentioned error, regardless of if it is decrypted files (regular encfs mount) or encrypted files (encfs --reverse mount)

So this led me to believe that this is an encfs4win error.

I can live without it by either pre-encrypt the files locally before sending them (but that takes a lot of additional hard dive space) or by using a linux VM to transfer the --reverse mounted drive, but it would be nice if this could be fixed.

jetwhiz commented 7 years ago

Could you provide some of the encfs logs of this happening? The logs should be located in your %TEMP% folder if you use the "-v" verbose flag. If you also use the "-f" foreground flag then they will appear in your terminal instead.

qnorsten commented 7 years ago

I am trying that now, is there any default filename for the logfile? My temp folder is a bit crowded

qnorsten commented 7 years ago

Just found the logs and this is the output after I run the following commands **1. encfs --reverse F:\Nedladdat Z: -v -- -o volname=NeddladdatF

  1. rclone copy z: Remote:test**
2016-11-28 21:24:43,498 VER [main.cpp:547] Closing stderr
2016-11-28 21:24:53,085 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:53,113 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:53,115 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:53,143 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:53,144 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:53,605 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:53,606 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:55,577 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:55,602 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:55,602 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:55,622 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:24:55,622 VER [encfs.cpp:764] doing statfs of F:\Nedladdat

So nothing interested in that. Even though I also discovered a lot of these entries, after I started browsing folders in the reversly mounted drive with windows explorer (I do not know if it is related or not)

2016-11-28 21:22:24,722 VER [main.cpp:547] Closing stderr
2016-11-28 21:22:30,759 VER [StreamNameIO.cpp:177] checksum mismatch: expected 43402, got 12066
2016-11-28 21:22:30,759 VER [StreamNameIO.cpp:178] on decode of 6 bytes
2016-11-28 21:22:30,760 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:30,762 VER [encfs.cpp:248] readdir on F:\Nedladdat/
2016-11-28 21:22:30,951 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:30,951 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:32,039 VER [StreamNameIO.cpp:177] checksum mismatch: expected 43402, got 12066
2016-11-28 21:22:32,040 VER [StreamNameIO.cpp:178] on decode of 6 bytes
2016-11-28 21:22:32,040 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:32,072 VER [encfs.cpp:248] readdir on F:\Nedladdat/Filmer
2016-11-28 21:22:32,957 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:32,981 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:32,981 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:34,726 VER [encfs.cpp:248] readdir on F:\Nedladdat/
2016-11-28 21:22:34,815 VER [StreamNameIO.cpp:177] checksum mismatch: expected 11037, got 65479
2016-11-28 21:22:34,815 VER [StreamNameIO.cpp:178] on decode of 5 bytes
2016-11-28 21:22:34,815 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:34,815 VER [StreamNameIO.cpp:177] checksum mismatch: expected 11037, got 38635
2016-11-28 21:22:34,815 VER [StreamNameIO.cpp:178] on decode of 5 bytes
2016-11-28 21:22:34,815 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:34,815 VER [encfs.cpp:248] readdir on F:\Nedladdat/Filmer
2016-11-28 21:22:35,083 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:35,084 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:22:35,497 VER [StreamNameIO.cpp:177] checksum mismatch: expected 43402, got 12066
2016-11-28 21:22:35,498 VER [StreamNameIO.cpp:178] on decode of 6 bytes
2016-11-28 21:22:35,498 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:35,499 VER [StreamNameIO.cpp:177] checksum mismatch: expected 11037, got 65479
2016-11-28 21:22:35,499 VER [StreamNameIO.cpp:178] on decode of 5 bytes
2016-11-28 21:22:35,499 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:35,499 VER [StreamNameIO.cpp:177] withFileNode: error caught in getattr: checksum mismatch in filename decodechecksum mismatch: expected 11037, got 65479
2016-11-28 21:22:35,499 VER [StreamNameIO.cpp:178] on decode of 5 bytes
2016-11-28 21:22:35,500 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:35,500 VER [StreamNameIO.cpp:177] checksum mismatch: expected 11037, got 38635
2016-11-28 21:22:35,500 VER [StreamNameIO.cpp:178] on decode of 5 bytes
2016-11-28 21:22:35,500 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode
2016-11-28 21:22:35,500 VER [StreamNameIO.cpp:177] checksum mismatch: expected 11037, got 38635
2016-11-28 21:22:35,500 VER [StreamNameIO.cpp:178] on decode of 5 bytes
2016-11-28 21:22:35,500 ERROR [default] withFileNode: error caught in getattr: checksum mismatch in filename decode

If I successfully transfer a file from the root of the mounted drive by running rclone copy Z:\at3QHzdxvp8-ivlvB1 Remote:test the logs shows these entries 

2016-11-28 21:31:13,778 VER [main.cpp:547] Closing stderr
2016-11-28 21:31:21,858 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:21,875 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:21,876 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:22,469 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:22,476 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:25,910 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:25,910 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:27,954 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:27,971 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:27,972 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:27,999 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:28,000 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
2016-11-28 21:31:43,701 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:43,702 VER [RawFileIO.cpp:137] open file with flags 0, result = 4
2016-11-28 21:31:43,702 VER [encfs.cpp:653] encfs_open for F:\Nedladdat/.encfs6.xml, flags 0
2016-11-28 21:31:43,702 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:43,702 VER [RawFileIO.cpp:122] using existing file descriptor
2016-11-28 21:31:45,561 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:45,561 VER [RawFileIO.cpp:137] open file with flags 0, result = 4
2016-11-28 21:31:45,561 VER [encfs.cpp:653] encfs_open for F:\Nedladdat/.encfs6.xml, flags 0
2016-11-28 21:31:45,562 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:45,562 VER [RawFileIO.cpp:122] using existing file descriptor
2016-11-28 21:31:45,774 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:45,774 VER [RawFileIO.cpp:137] open file with flags 0, result = 4
2016-11-28 21:31:45,774 VER [encfs.cpp:653] encfs_open for F:\Nedladdat/.encfs6.xml, flags 0
2016-11-28 21:31:45,776 VER [CipherFileIO.cpp:332] streamRead(data, 66, IV)
2016-11-28 21:31:46,083 VER [CipherFileIO.cpp:332] streamRead(data, 66, IV)
2016-11-28 21:31:46,892 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:46,892 VER [RawFileIO.cpp:122] using existing file descriptor
2016-11-28 21:31:46,892 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:46,892 VER [RawFileIO.cpp:137] open file with flags 0, result = 4
2016-11-28 21:31:46,892 VER [encfs.cpp:653] encfs_open for F:\Nedladdat/.encfs6.xml, flags 0
2016-11-28 21:31:46,892 VER [RawFileIO.cpp:116] open call, requestWrite = 0
2016-11-28 21:31:46,892 VER [RawFileIO.cpp:122] using existing file descriptor
jetwhiz commented 7 years ago 
VER [StreamNameIO.cpp:177] checksum mismatch: expected 43402, got 12066

Are you using Block or Block32 filename encoding? For Windows you should be using Block32 (since Windows is case sensitive).

qnorsten commented 7 years ago

I am not 100% sure, I think I am using stream. Followed this guide (https://www.andreagrandi.it/2014/09/12/create-an-encfs-volume-compatible-with-boxcryptor-classic/) to setup the initial encfs container as I initialy used boxcryptor classic (before finding this new updated version of encfs4windows)

jetwhiz commented 7 years ago

It looks like the checksum mismatch is coming from the desktop.ini files that Windows keeps trying to create (which encfs thinks are encrypted filenames). They should not be causing any issues, but are mostly just annoying.

Can you add the "-d" Dokany debug flag as well and see what happens (using rclone, not Explorer). The log file will likely be very large with this, though.

qnorsten commented 7 years ago

Ok then I keep ignoring that error.

I added the -d flag and tried to run again here is the current log rclone copy z: Remote:test

2016-11-28 22:18:58,241 VER [main.cpp:547] Closing stderr
Dokan: debug mode on
Dokan: use stderr
AllocationUnitSize: 512 SectorSize: 512
device opened
###QueryVolumeInfo -001
GetVolumeInformation
mounted: Z: -> \Volume{d6cc17c5-1738-4085-bce7-964f1e9f5de9}
Mounted
###Create 0000
CreateFile: \
    DesiredAccess: SYNCHRONIZE
    ShareAccess: 0x0
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 33 (0x21)
CreateFile status = 0
###GetFileInfo 0000
GetFileInfo: : \
    result =  0
  unknown type:54
    DispatchQueryInformation result =  c000000d
###GetFileInfo 0000
GetFileInfo: : \
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###QueryVolumeInfo 0000
GetVolumeInformation
###QueryVolumeInfo 0000
GetVolumeInformation
###Cleanup 0000
Cleanup: \

###Close 0000
Close: \

###Create 0001
CreateFile: \
    DesiredAccess: SYNCHRONIZE
    ShareAccess: 0x0
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 8388641 (0x800021)
CreateFile status = 0
###GetFileInfo 0001
GetFileInfo: : \
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###QueryVolumeInfo 0001
GetDiskFreeSpace
2016-11-28 22:19:01,281 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
###Cleanup 0001
Cleanup: \

###Close 0001
Close: \

###Create 0002
CreateFile: \
    DesiredAccess: SYNCHRONIZE
    ShareAccess: 0x0
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 8388641 (0x800021)
CreateFile status = 0
###GetFileInfo 0002
GetFileInfo: : \
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###QueryVolumeInfo 0002
GetDiskFreeSpace
2016-11-28 22:19:01,296 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
###Cleanup 0002
Cleanup: \

###Create 0003
###Close 0002
CreateFile: \
Close: \

    DesiredAccess: SYNCHRONIZE
    ShareAccess: 0x0
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 8388641 (0x800021)
CreateFile status = 0
###GetFileInfo 0003
GetFileInfo: : \
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###QueryVolumeInfo 0003
GetDiskFreeSpace
2016-11-28 22:19:01,297 VER [encfs.cpp:764] doing statfs of F:\Nedladdat
###Cleanup 0003
Cleanup: \

###Close 0003
Close: \

###Create 0004
CreateFile: \
    DesiredAccess: SYNCHRONIZE
    ShareAccess: 0x0
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 33 (0x21)
CreateFile status = 0
###GetFileInfo 0004
GetFileInfo: : \
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###Create 0005
CreateFile: \
    DesiredAccess: SYNCHRONIZE
    ShareAccess: 0x0
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 33 (0x21)
CreateFile status = 0
###GetFileInfo 0005
GetFileInfo: : \
###QueryVolumeInfo 0004
GetVolumeInformation
###QueryVolumeInfo 0004
GetVolumeInformation
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###Cleanup 0004
Cleanup: \

###QueryVolumeInfo 0005
GetVolumeInformation
###QueryVolumeInfo 0005
GetVolumeInformation
###Close 0004
Close: \

###Cleanup 0005
Cleanup: \

###Close 0005
Close: \

###Create 0006
CreateFile: \
    DesiredAccess: SYNCHRONIZE|FILE_READ_ATTRIBUTES|FILE_READ_DATA
    ShareAccess: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 0 (0x0)
CreateFile status = 0
###GetFileInfo 0006
GetFileInfo: : \
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###GetFileInfo 0006
GetFileInfo: : \
    result =  0
    FileBasicInformation
    DispatchQueryInformation result =  0
###Create 0007
CreateFile: \
    DesiredAccess: SYNCHRONIZE|FILE_READ_ATTRIBUTES|FILE_READ_DATA
    ShareAccess: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 0 (0x0)
CreateFile status = 0
###GetFileInfo 0007
GetFileInfo: : \
    result =  0
    FileBasicInformation
    DispatchQueryInformation result =  0

Here is the log file after running dokanctl.exe /u z: to unmount the drive

http://pastebin.com/QjeLcXY9

jetwhiz commented 7 years ago 
Ioctl failed for wait with code 995.
Ioctl failed for wait with code 995.
Thread will be terminated
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Ioctl failed for wait with code 995.
Thread will be terminated
Dokan Error: DokanKeepAlive CreateFile failed \\.\Volume{d6cc17c5-1738-4085-bce7-964f1e9f5de9}: 2
Unmount

This part is expected, and is a known bug in Dokany that has been fixed (so the next release candidate shouldn't have this issue).

The rest of the debug information looks mostly normal to me though. You're receiving the "Local file system at \?\X:: Failed to open directory: \?\X:: Readdir \?\X:: The system cannot find the path specified." error message with that debug output?

qnorsten commented 7 years ago

Yes, here is the command promt output (some error messages are localized to Swedish)

http://imgur.com/a/0Loaq

Here is the log from this session (have not unmounted yet) http://pastebin.com/vsUaEPF1

jetwhiz commented 7 years ago

Can you try this with the Dokany fuse_mirror sample and see if the problem exists there, too?

It is located in "C:\Program Files\Dokan\Dokan Library-1.0.1\sample\fuse_mirror", and you need Cygwin to be installed to run it.

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

qnorsten commented 7 years ago

I ran mirror.exe Z: from the fuse_mirror folder and got no error or anything in the commandpromt, but I also can not access Z: anymore

jetwhiz commented 7 years ago

I would try again, or use a different drive letter to mount to (maybe Z: was already mounted). You should be able to at least browse files in the mounted drive letter.

qnorsten commented 7 years ago

Tried again this time with fuse_mirror by running mirror X: now I get a drive with some cygwin files in it. It gives me the same error as before if I try to copy it with rclone.

Also realized rclone has a mode to disable conversion of paths to UNC tried that, but still got a similar error.

With UNC enabled Local file system at \?\X:\: failed to read directory "\\?\X:\": Readdir \?\X:\: Det går inte att hitta sökvägen.

With UNC disabled Local file system at X:\: failed to read directory "X:\": Readdir X:\: Det går inte att hitta sökvägen.

Det går inte att hitta sökvägen is Swedish for The system cannot find the path specified.

jetwhiz commented 7 years ago

Ok, that makes sense then. Reading through your original bug report (on rclone), I think klauspost is correct in saying:

ok, it is somewhere in the directory reading code, most likely Dokan returning a wrong value somewhere.

The only way I can see this triggering is if opening the directory as a file does NOT return an error.

Go first tries to open a file as a plain file, if that fails, it tries as a directory before failing. It seems like Dokan/encfs reports "success" when opening z:\ as a file, which it shouldn't, since it isn't a file.

Go is attempting to open the folder as a file, which Dokany is apparently doing without any complaints. Can you file a bug report on the Dokany project to detail this bug (https://github.com/dokan-dev/dokany)? Make sure to mark that this is a bug with FUSE and not Dokany (Library type (Dokany/FUSE): ).

I can create the issue for you if you prefer, and you can add your own information to it after -- just let me know!

qnorsten commented 7 years ago

The issue on rclone is not mine, just someone else that had the same problem, but guess klauspost was right then.

I would appreciate if you would create the issue, so it gets done right. It looked a bit intimidating to create issue on the dokany project as they seem to be a bit picky, about formatting and what information to include.

jetwhiz commented 7 years ago

@qnorsten -- I have created a bug report here: https://github.com/dokan-dev/dokany/issues/406

If you would like to add any additional information then you can add it there. I will follow this bug so we can hopefully get it fixed in encfs4win for the next release candidate.

qnorsten commented 7 years ago

Thanks I think you got all the important info there already. I will follow that issue also, in case the donaky dev wants some more information. Thank you for your help, and for maintaining this project:)

jetwhiz commented 7 years ago

No problem! It's likely this bug will need to be fixed in both the Dokany FUSE mirror and encfs.

If you have access to a Linux machine, can you test this out with the upstream encfs as well? I think this issue might be affecting the main encfs project.

qnorsten commented 7 years ago

I do not have the same problem with the encfs version installed by sudo apt-get install encfs on a virtual Ubuntu machine at least.

jetwhiz commented 7 years ago

That's strange -- is that running v1.8.1 or v1.7.4 of encfs?

qnorsten commented 7 years ago

Running v1.7.4. I just shared the regular folder from windows over smb, and mounted it on ubuntu VM and then did a reverse mount with encfs on the mounted folder, and it works perfectly.

Steps in summary

jetwhiz commented 7 years ago

Ok, with v1.7.4 that makes more sense, since readOnly is not forced for reverse mode in that version (from what I can tell). This will cause the open on a directory to fail (which Go is intending). Is there any way you can try this with the latest version, v1.9.1?

Are you using per-file Initialization Vector (uniqueIV)?

qnorsten commented 7 years ago

I am currently in the middle of a big upload, but can try to update encfs when it is complete. I am 98.7 % sure that I am not using per-file Initialization Vector. Is it a way to check that so I can be 100% sure?

jetwhiz commented 7 years ago

It should be listed under "uniqueIV" in your .encfs6.xml config file.

qnorsten commented 7 years ago

It has the value 0, so I am not using it. What is the best way to install v1.9.1 on Ubuntu 15.04? Build from source or something easier?

Update: trying to build it from source now, will let you know how it goes

qnorsten commented 7 years ago

Just tried the same thing with encfs v 1.9.1 build from source on the Ubuntu VM, no error. everything seem to work as expected.

jetwhiz commented 7 years ago

~It should work correctly with uniqueIV disabled in reverse mode (since it is opened as read-write) -- can you try to create a filesystem with uniqueIV enabled and see if it works correctly?~

Actually, scratch that -- I just looked at the Go implementation for Unix and it does not behave the same way: https://github.com/golang/go/blob/master/src/os/file_unix.go#L86

So it looks like this "open directory as file" issue only affects their Windows implementation.

qnorsten commented 7 years ago

Ok was just gooing to try that, but now I guess it is not needed. Then the only question is, should encfs/dokan fix this issue, or should someone create an issue on go and see if they can fix their windows implementation?

qnorsten commented 7 years ago

@jetwhiz this is fixed in dokany now:)