search

jetwhiz / encfs4win

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

Inconsistent display of files based on their size while using Null filename encryption #82

Closed vovcacik closed 7 years ago

vovcacik commented 7 years ago

Environment

Description

When I use Null filename encryption and I create two files in root directory (i.e. where files are encrypted) - one empty and one of non zero size - the empty file will "leak" to the encrypted disk, while the other file won't.

Expected behavior vs. actual behavior

I would expect something consistent. Either hide all files that were not created through encfs but are present in root directory. Or show them regardless their size. Only empty files are shown now.

Steps to reproduce problem

Create the encfs disk with default values but select Null filename encryption.

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

echo 1234 > "%temp%\bug\nonempty.txt"
type nul > "%temp%\bug\empty.txt"

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

Relevant logs

Nothing useful in verbose logs.

Display Rules

vovcacik commented 7 years ago

And the encfs xml config file is always shown regardless its size.

vovcacik commented 7 years ago

Seems like all files starting with <?xml are shown, not just the encfs xml config.

vovcacik commented 7 years ago

This is related to #84 but I focus on file size here, while the first focuses on file content, <?xml to be precise.

jetwhiz commented 7 years ago

For this particular issue, this might be expected behavior (with null filename encryption). If there are no contents to the file, then there is no way for encfs to know if the decryption is successful or not (since there is no content to verify).

encfs does not track which files it placed in the directory (since you should be able to dynamically copy encrypted files from other people/computers and have it just work).

vovcacik commented 7 years ago

Yeah that would make sense. The inconsistency may be bit confusing to the user, but I see why it is necessary.

That would explain 90% of this issue; the rest of it I have moved to a comment on issue #81, which seems now as more relevant place to discuss it. You can close this.