[FIXED] Discrepancy between the file sizes about securefs HOT 21 CLOSED

I tested Windows 10 and there is the same problem.

Seems to be a bug in LiteDirectoryTraverser L329 on windows. It receives the encrypted file size from storage backend, but on linux there is no problem.

One solution here could be to call AESGCMCryptStream::calculate_real_size after we receive the (encrypted) file size (stbuf->st_size) on windows.

Maybe @netheril96 can clarify.

from securefs.

It seems to be the malady of SecureFS’s lite format 4, since formats 1, 2, 3 have no such discrepancy.

from securefs.

Indeed a call to AESGCMCryptStream::calculate_real_size is needed here. The bug doesn't show up on Linux and macOS because FUSE API reads only the type field in the stbuf buffer during directory traversal. The file sizes are reported by stat syscall instead. On Windows, WinFSP has an option I turn on by default to consolidate the calls. In other words, the stbuf->st_size is only read on Windows.

A fix is on the way.

from securefs.

Fixed in 324a92f.

from securefs.

Long awaited fix indeed, thank you.
I hope an updated binary is on the way as well, since am a mere user without compilers.

from securefs.

New binary released.

from securefs.

New binary throws errors while trying to perform basic tasks like creating a new file or a folder:

[Info] [00000000000005A0] [... UTC]    init
The service securefs has been started.
[Error] [00000000000006E0] [... UTC]    chown path=/New Text Document.txt encounters exception class securefs::VFSException (code=40): Function not implemented
[Error] [00000000000006E0] [... UTC]    chown path=/November encounters exception class securefs::VFSException (code=40): Function not implemented

from securefs.

Does it affect usage?

from securefs.

Yes, Windows Explorer and other file managers display error messages every now and then.
And it saddens me deeply, bearing in mind that sensitive data is at stake.

from securefs.

I can't reproduce the error locally. Can you provide more information? Which operating system, 32 or 64 bit, what filesystem on, what exactly you do that leads to these errors.

from securefs.

Windows 7 x64, NTFS, create a new folder and a text file via Windows Explorer context menu.

$ securefs080 c c:\Vault4-080
$ securefs080 m c:\Vault4-080 z:
[Error] [0000000000000708] [2017-11-02 ...]    chown path=/New folder encounters exception class securefs::VFSException (code=40): Function not implemented
[Error] [00000000000000B0] [2017-11-02 ...]    chown path=/New Text Document.txt encounters exception class securefs::VFSException (code=40): Function not implemented

Notwithstanding the errors displayed by both SecureFS 0.8.0 and Windows Explorer, I see a folder and a file eventually, but clearly something is broken. On the contrary, SecureFS 0.7.3 works smoothly:

$ securefs073 c c:\Vault4-073
$ securefs073 m c:\Vault4-073 x:

No errors.

from securefs.

Please mount with option --trace and post the log.

from securefs.

https://www.pastery.net/gfwhjt/raw/

from securefs.

Hmmm....there is no call to chown in my trace log on Windows 10. What is the version of WinFsp on your system?

from securefs.

Tried the latest WinFsp 2017.2 B2 and the previous WinFsp 2017.2 B1. Obviously, this is about changes you introduced in 0.8.0, not WinFSP or anything else, as 0.7.3 works fine. Review what was done above the initial request to fix file sizes discrepancy to get to the crux of the matter. And, frankly, I would refrain from using Windows 10, let alone developing on.

from securefs.

The two releases are not separated by this single commit. The cause are likely elsewhere. Since I cannot find the root cause, I decide to just silence it, as it is not easy to implement access control on Window right.

Please test this new binary.

securefs-win.zip

from securefs.

New binary works without aforementioned errors, bravo!

from securefs.

BTW, why did you choose to go with Scrypt from now on and not Argon2 (like KeePass did) or Lyra2?

from securefs.

Argon2 is too new so I have doubts about its security. I have never heard of Lyra2.

from securefs.

Since I cannot find the root cause, I decide to just silence it

Does it mean error is still there, but error message is simply no longer displayed?

from securefs.

The error is caused by chown syscall, which is never implemented on Windows. This commit simply turns it to a no-op if it is ever called.

from securefs.