How to obtain or simulate the remaining space of drive redirection

[tsz8899]

Currently, chansrv can properly handle drive redirection.
The remaining space seen by the operating system is 0.

However, some specific programs, such as browsers, check whether there is enough storage space when downloading and saving files.
Due to the remaining space being 0, it is impossible save to drive redirection.

How can we make the operating system recognize the remaining space for drive redirection?
Or directly inform the system that there is 100GB of available space?

Thanks

[matt335672]

Hi @tsz8899

As always from you, this is an interesting and though-provoking observation.

I don't think there's anything in the protocol to support this kind of direct query. I tested that with a couple of Windows 10 VMs, with the reasoning that if Microsoft supports it we should be able to.

I ran mstsc.exe and asked to pass through just the C drive. Here is what I get:-

The redirected drive does not display its free space, nor could I find a way to make it.

So I think the only way to proceed would be to supply a dummy value which chansrv could pass back to the statfs system call. It wouldn't be just the value though - If I understand it correctly we'd have to link an additional method into g_xfuse_ops.statfs in chansrv_fuse.c to pass back an entire struct statfs

Thoughts?

[tsz8899]

Come into force!@@

chansrv_fuse.c .h

fuse_lowlevel.h
statvfs.h

#define XFUSE_ENTRY_TIMEOUT     5.0

void xfuse_cb_statfs(fuse_req_t req, fuse_ino_t ino) {  
    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 = (100 * 1024 * 1024) / vfs_stats.f_bsize; 
    vfs_stats.f_bfree = (50 * 1024 * 1024) / vfs_stats.f_bsize; 
    vfs_stats.f_bavail = vfs_stats.f_bfree; 
    fuse_reply_statfs(req, &vfs_stats);  
}  

and
g_xfuse_ops.statfs      = xfuse_cb_statfs;

thank
If you have time please see how to do better

[matt335672]

Leave it with me. I'll try to add a configurable value somewhere. But I think what you've added is pretty much what we'd have to do.

Once again, thanks for the idea!

[tsz8899]

After modifying the code, I encountered a VFS fuse kernel error that I had never seen before.
not sure if there is a causal relationship.

All existing and new features functioned normally during frequent use. This fuse error occurred only once.

[   14.061645] grep (2891) used greatest stack depth: 10616 bytes left
[49210.651600] traps: Chrome_ChildIOT[286858] trap invalid opcode ip:56444b0bdb16 sp:7f9c047fe000 error:0 in browser[ba05b16,564441dad000+c7a7000]
[49288.754783] VFS: Busy inodes after unmount of fuse (fuse)
[49288.754902] ------------[ cut here ]------------
[49288.755072] kernel BUG at fs/super.c:652!
[49288.755179] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[49288.755266] CPU: 20 PID: 294794 Comm: fusermount Not tainted 6.10.8#6
[49288.755353] Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.15.0-2.module+uelc20+875+45dcb3cf 04/01/2014
[49288.755448] RIP: 0010:generic_shutdown_super+0x102/0x110
[49288.755587] Code: cc cc e8 e1 44 f2 ff 48 8b bb 00 01 00 00 eb d9 48 8b 43 28 48 8d b3 c0 03 00 00 48 c7 c7 40 d6 67 92 48 8b 10 e8 3e d7 d2 ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
[49288.755750] RSP: 0018:ffffa7424bae7e18 EFLAGS: 00010246
[49288.755820] RAX: 000000000000002d RBX: ffff8a47bee30000 RCX: 0000000000000001
[49288.755890] RDX: 0000000000000000 RSI: ffffffff92659e24 RDI: 00000000ffffffff
[49288.755957] RBP: ffffa7424bae7e28 R08: 0000000000000000 R09: c0000000ffff7fff
[49288.756029] R10: 0000000000000001 R11: ffffa7424bae7c00 R12: ffffffff920987c0
[49288.756095] R13: ffff8a4bd8a38000 R14: ffff8a4bd8a38cbc R15: ffffffff933887b0
[49288.756170] FS:  00007fa43cb9e580(0000) GS:ffff8a653c800000(0000) knlGS:0000000000000000
[49288.756247] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[49288.756330] CR2: 00007ffd9d3f2578 CR3: 0000000c252a6006 CR4: 0000000000770ef0
[49288.756397] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[49288.756481] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[49288.756549] PKRU: 55555554
[49288.756613] Call Trace:
[49288.756698]  <TASK>
[49288.756767]  ? show_regs+0x61/0x70
[49288.756862]  ? __die_body+0x1f/0x70
[49288.756927]  ? die+0x3d/0x60
[49288.756992]  ? do_trap+0xd4/0xf0
[49288.757062]  ? do_error_trap+0x73/0xa0
[49288.757135]  ? generic_shutdown_super+0x102/0x110
[49288.757205]  ? exc_invalid_op+0x52/0x70
[49288.757329]  ? generic_shutdown_super+0x102/0x110
[49288.757441]  ? asm_exc_invalid_op+0x1b/0x20
[49288.757614]  ? generic_shutdown_super+0x102/0x110
[49288.757703]  ? generic_shutdown_super+0x102/0x110
[49288.757785]  kill_anon_super+0x18/0x50
[49288.757862]  fuse_kill_sb_anon+0x1a/0x30
[49288.757962]  deactivate_locked_super+0x32/0x90
[49288.758028]  deactivate_super+0x59/0x60
[49288.758103]  cleanup_mnt+0xbd/0x150
[49288.758189]  __cleanup_mnt+0x12/0x20
[49288.758263]  task_work_run+0x65/0xa0
[49288.758360]  syscall_exit_to_user_mode+0x1b4/0x1c0
[49288.759362]  do_syscall_64+0x56/0x140
[49288.759709]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[49288.760028] RIP: 0033:0x7fa43cae09e7
[49288.760355] Code: 64 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 79 64 0b 00 f7 d8 64 89 01 48
[49288.760934] RSP: 002b:00007ffd9d4025a8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a6
[49288.761269] RAX: 0000000000000000 RBX: 000000000e780460 RCX: 00007fa43cae09e7
[49288.761554] RDX: 0000000000000000 RSI: 000000000000000a RDI: 000000000e780471
[49288.761840] RBP: 00007fa43cb9e500 R08: 000000003fffffff R09: 00007fa43cb980e0
[49288.762136] R10: 000000000e77f010 R11: 0000000000000206 R12: 000000000000000a
[49288.762415] R13: 000000000e781026 R14: 00007ffd9d402920 R15: 00000000ffffffff
[49288.762686]  </TASK>
[49288.762934] Modules linked in: nfnetlink_queue nfnetlink_log nfnetlink bluetooth intel_rapl_msr intel_rapl_common intel_uncore_frequency_common isst_if_common skx_edac_common nfit kvm_intel hid_generic usbip_core kvm rapl usbhid input_leds joydev bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm mac_hid serio_raw pcspkr ip_tables x_tables crct10dif_pclmul crc32_pclmul ghash_clmulni_intel sha512_ssse3 sha256_ssse3 sha1_ssse3 virtio_scsi psmouse i2c_piix4 floppy pata_acpi aesni_intel crypto_simd cryptd
[49288.764842] ---[ end trace 0000000000000000 ]---
[49288.765199] RIP: 0010:generic_shutdown_super+0x102/0x110
[49288.765566] Code: cc cc e8 e1 44 f2 ff 48 8b bb 00 01 00 00 eb d9 48 8b 43 28 48 8d b3 c0 03 00 00 48 c7 c7 40 d6 67 92 48 8b 10 e8 3e d7 d2 ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
[49288.766175] RSP: 0018:ffffa7424bae7e18 EFLAGS: 00010246
[49288.766454] RAX: 000000000000002d RBX: ffff8a47bee30000 RCX: 0000000000000001
[49288.766747] RDX: 0000000000000000 RSI: ffffffff92659e24 RDI: 00000000ffffffff
[49288.767023] RBP: ffffa7424bae7e28 R08: 0000000000000000 R09: c0000000ffff7fff
[49288.767302] R10: 0000000000000001 R11: ffffa7424bae7c00 R12: ffffffff920987c0
[49288.767701] R13: ffff8a4bd8a38000 R14: ffff8a4bd8a38cbc R15: ffffffff933887b0
[49288.768104] FS:  00007fa43cb9e580(0000) GS:ffff8a653c800000(0000) knlGS:0000000000000000
[49288.768481] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[49288.768862] CR2: 00007ffd9d3f2578 CR3: 0000000c252a6006 CR4: 0000000000770ef0
[49288.769245] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[49288.769625] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[49288.770027] PKRU: 55555554

[matt335672]

For reference, what's your kernel version?

This one looks similar (kernel BUG at fs/super.c):-

https://bugzilla.kernel.org/show_bug.cgi?id=219097

[tsz8899]

thank

kernel is 6.10.8
no errors related to FUSE have been found again. I will continue to observe for a few more

[matt335672]

@tsz8899

I've been looking at the Microsoft documents related to the remote filesystem, and I think I've given you incorrect information. It may be possible to query the free space after all.

Relevant sections are

• [MS-RDPEFS] 2.2.3.3.6 DR_DRIVE_QUERY_VOLUME_INFORMATION_REQ with FsInformationClass set to FileFsFullSizeInformation
• [MS-FSCC] 2.5.4 which documents the corresponding FileFsFullSizeInformation structure.

I'm a little short of time to look at this at the moment, but it looks promising.