Add support for statvfs() to FUSE

[matt335672]

Fixes #3300

See also #3246

Some desktop environments are now checking for free space before copying files to a destination.

To support this, the FUSE filesystem needs to convert the statfs()/statvfs() system call to the relevant PDUs from [MS-RDPEFS]

Draft for now - I'd really appreciate comments from @tsz8899 (if possible).

Edit 24-10-14 : No longer draft

[matt335672]

A screenshot from a remote session with a 119GB C: drive and a 5MB E: drive passed through:-

$ df -h ~/thinclient_drives/ ~/thinclient_drives/C\:/ ~/thinclient_drives/E\:/
Filesystem      Size  Used Avail Use% Mounted on
xrdp-chansrv    0.0K  0.0K  0.0K    - /home/testuser/thinclient_drives
xrdp-chansrv    119G   53G   67G  45% /home/testuser/thinclient_drives
xrdp-chansrv    5.0M  3.6M  1.5M  71% /home/testuser/thinclient_drives

Because we only use a single mountpoint for the remote client (with all the drives underneath), the xrdp session is unable to distinguish between them - it just sees the mount on ~/thinclient_drives.

Firefox and Dolphin seem OK with this (as they presumably run statvfs() on the target directory), but chromium on Fedora 41 doesn't - it seems to be defaulting to the freespace as returned from the mountpoint. As a result I can't browse down to the C: drive and save anything. However, the chromium snap on Ubuntu 22.04 works OK.

Update: Even with some fake diskspace added, chromium on Fedora 41 won't let me save anything. This needs further investigation.

@tsz8899 - which browser/platform were you using in #3246?

[tsz8899]

On my old testing platform, there was a similar issue: "Chromium cannot browse to the C: drive."
However, manually specifying the save path as "thinclient_drives/C/ .../.../../" allows for saving.
The environment without problems: Linux + fuse2 3 + dbus-user-session.
problematic environment: Deepin Linux + fuse2 3 + namespace + dbus-user-session.
The reason is that there is a conflict between fuse mounts and dbus-user-session in a namespace environment.

Effective solutions:
A. Remove dbus-user-session in the namespace environment.
B. Disable the namespace and keep fuse + dbus-user-session.

This time, a new platform was built for testing, and the operating system was updated. A similar phenomenon was discovered.
This phenomenon has likely existed in my environment for a long time, but it was difficult to detect.
Because if there are many files in the user's personal directory, or if the file manager is set to show hidden files, it will not trigger and will work normally.
If the newly created user directory has fewer files and hidden files are not set to display, it is more likely to trigger.
The phenomenon:
When using Chromium browsers based on 90 and 108, the "thinclient_drives" storage location appears grayed out when selecting a save location for the first time, preventing the path selection dialog from opening.
After refreshing the directory in the browser, files can be recognized and saved. For example:
A. Accessing other directories and the thinclient_drives directory once using the browser allows the browser to recognize it afterward.
B. If the browser cannot choose the storage location, manually specifying the save path as "thinclient_drives/.../" once will make "thinclient_drives" available for the remainder of that session.
C. Canceling the save and selecting the save location again.
D. Alternatively, setting "thinclient_drives" as the default save path.
In my environment, this phenomenon disappears after the file manager is set to show hidden files.

However, the Microsoft Edge for Linux browser (chromium 130) does not have this issue!
Does the Edge browser pre-read the user directory at startup?

Adding the following code did not change the phenomenon:

static void xfuse_cb_statfs(fuse_req_t req, fuse_ino_t ino)
{
    XFS_INODE        *xinode;
    struct statvfs vfs_stats;
    memset(&vfs_stats, 0, sizeof(vfs_stats));
    vfs_stats.f_bsize = 4096;
    vfs_stats.f_frsize = 4096;
    vfs_stats.f_blocks = (long long)(8999) * 1024 * 1024 / vfs_stats.f_bsize; 
    vfs_stats.f_bfree = (long long)(8899) * 1024 * 1024 / vfs_stats.f_bsize; 
    vfs_stats.f_bavail = vfs_stats.f_bfree;
    fuse_reply_statfs(req, &vfs_stats);

minor issue that does not affect usability.:
Test environment: Deepin Debian Linux +mstsc client.

df -h ~/thinclient_drives/ ~/thinclient_drives/C\:/ ~/thinclient_drives/D\:/
xrdp-chansrv    0.0K  0.0K  0.0K    - /home/testuser/thinclient_drives
xrdp-chansrv    58G   27G   31G   47% /home/testuser/thinclient_drives  ---is OK
xrdp-chansrv    359G  178G  181G   50% /home/testuser/thinclient_drives  ---is OK

Test environment: Deepin Debian Linux + wfreerdp and xfreerdp client(maybe freerdp issue).

df -h ~/thinclient_drives/ ~/thinclient_drives/C/ ~/thinclient_drives/D/
Filesystem      Size  Used Avail Use% Mounted on
xrdp-chansrv    0.0K  0.0K  0.0K    - /home/testuser/thinclient_drives
xrdp-chansrv    23P   12P   12P   47% /home/testuser/thinclient_drives  ---size error
xrdp-chansrv    3.6P  1.7P  2.0P   50% /home/testuser/thinclient_drives  ---size error

[tsz8899]

There is a fuse mount situation that I am unsure if it is relevant:

When the system enables namespaces and removes dbus-user-session, the operating system and browser can access thinclient_drives normally.

However, when the system enables namespaces and uses dbus-user-session,
The issue occurs 100%: the operating system can access thinclient_drives, but the browser cannot recognize the thinclient_drives (can't browse down any drive).

Feedback from the operating system developers is as follows:
The reason the program cannot receive mount events is that after setting up namespaces, a new mount namespace is created upon re-logging into the system.
At this point, the desktop session and the mount monitoring service are located in different mount namespaces.
This results in the mounted file systems in the desktop session not being monitored by the service, causing applications in the desktop session to be unable to receive mount events.

The suggested workaround is to try executing the mount operation through user services.
user login systemctl --user start fusemount.service

[matt335672]

Thanks @tsz8899

Do you know what version of xfreerdp your wfreerdp client is built with? I've just tried with xfreerdp 3.7 from a Linux machine and the results seem correct.

The environment you are describing (mount namespaces and monitoring on a desktop) is unfamiliar to me. Is this a Deepin-specific feature?

My own issue with chromium on Fedora41 is different, and not namespace related. If I browse to the thinclient directory and open the save dialog box (say for an iso image), chromium starts downloading the file to the directory in a hidden file:-

$ ls -lah ~/thinclient_drives/_home_mj/
. . .
total 0

-rw-------. 1 testuser testuser 379M Nov 11 10:59  .org.chromium.Chromium.YSyVe4

However, the Save button is still greyed out.

[matt335672]

Just found my Chromium problem - Chromium wants f_namemax to be set for the filesystem.