Drive space info missing in Explorer

[leochou0729]

Hello, I try to mount a encfs drive with a source folder containing Chinese characters, the drive space info in explorer is missing. Instead, it shows the encfs absolute path. The source folder is utf-8 encoded. The drive works without any problem. I'm not sure the issue is related to encfs or fuse.

Using all English characters in source path doesn't have this problem.

BTW, I have two more questiones.

1. The encfs source uses lastPathElement() function to get the executable name and passes it through to fuse, but it seems that function doesn't take '\' into consideration, so it passes the absolute path of exe to fuse.
2. How is the space info calculated? The values seems meaningless in this context. Am I correct?

Thanks!

[leochou0729]

I think the problem lies in unix::statvfs() function. The path parameter is utf-8 encoded, so you cannot use it directly with GetDiskFreeSpaceExA api. I change the code as follows, then it works.

std::wstring fn(utf8_to_wfn(path));
if (!GetDiskFreeSpaceExW(fn.c_str(), &avail, &bytes, &free_bytes)) {
    errno = ERRNO_FROM_WIN32(GetLastError());
    return -1;
}

I found a big issue with the encfs code. It doesn't support utf-8 encoded arguements on Windows, including root dir and mount point. easylogging++ also cannot print utf-8 strings in console. The executable will halt if easylogging++ prints a character which is not in the ANSI code page. SetConsoleCP() doesn't help in this situation. Probably we need to use wmain entry point and convert command line arguments from wchar to utf-8. These are some articles discussing this problem, which I think might be helpful. https://entropymine.wordpress.com/2018/10/09/summary-of-some-win32-i-o-character-encoding-behavior/ https://entropymine.wordpress.com/2018/11/28/win32-i-o-character-encoding-part-2-chcp-65001/ https://entropymine.wordpress.com/2018/12/16/win32-i-o-character-encoding-part-3/

[jetwhiz]

Hi @leochou0729

Yes we've have issues reported with non-ANSI character sets, especially double-byte languages, in encfs4win (see https://github.com/jetwhiz/encfs4win/issues/55 and https://github.com/jetwhiz/encfs4win/issues/79).

Would you be able to draft up a PR with your findings so we can test this out? Or at least your update involving changing GetDiskFreeSpaceExA to GetDiskFreeSpaceExW?

Please let me know if you need any help with the codebase or our PR process!

[jetwhiz]

Hi @leochou0729 -- the latest beta version (v1.11.0-beta4) is built off of the latest Dokany library (v2), which should not be affected by this bug any longer.

If you have a chance, could you test out this beta to see if this bug still exists? https://github.com/jetwhiz/encfs4win/releases/tag/v1.11.0-beta.4