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

[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

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

• empty files are shown
• files starting with "<?xml " are shown
• non-empty files are hidden

[vovcacik]

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

[vovcacik]

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

[vovcacik]

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

[jetwhiz]

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]

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.