Skip to content

Report correct free space on large RDP redirected drives - #712

Open
benjefferies wants to merge 1 commit into
apache:mainfrom
benjefferies:rdp-drive-64bit-capacity
Open

Report correct free space on large RDP redirected drives#712
benjefferies wants to merge 1 commit into
apache:mainfrom
benjefferies:rdp-drive-64bit-capacity

Conversation

@benjefferies

Copy link
Copy Markdown

Summary

Windows Explorer can report no free space on an RDP-redirected Guacamole drive when the backing filesystem is large, even though writes that skip Explorer's pre-copy check still succeed. Copies of new files then fail with an insufficient-space error.

guac_rdp_fs_info stored blocks_available and blocks_total as int. guac_rdp_fs_get_info() copies statvfs counts into those fields, and RDPDR later writes them as UINT64 (FileFsSizeInformation / FileFsFullSizeInformation). On filesystems with more than 2^31 allocation units, the 32-bit value overflows — often to zero — so Windows believes the drive is full.

What changed

  • Store the allocation-unit counts as uint64_t, matching the RDPDR reply already being sent.

Notes

  • Same class of 32-bit truncation as GUACAMOLE-268 (file size) and GUACAMOLE-764 (read/write offsets).
  • Self-service registration on issues.apache.org is closed, so I could not file a new ticket. Happy to retitle once a committer files one or points me at the right account-request path.

Made with Cursor

RDPDR FileFsSizeInformation writes allocation-unit counts as UINT64,
but guac_rdp_fs_info stored them in a 32-bit int. Filesystems with
more than 2^31 allocation units then overflow, which can make Windows
report zero free space and refuse copies onto the redirected drive.

Related: GUACAMOLE-268, GUACAMOLE-764.
Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant