Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[V0.10] chansrv clip fixes #3194

Merged
merged 5 commits into from
Aug 6, 2024

Conversation

matt335672
Copy link
Member

Backport of #3165 / #3173 to V0.10

  • Much longer filenames are now supported by the redirector. This is useful when dealing with some character encodings which use 4-byte UTF-8 encoded characters.
  • Some hard-coded buffer sizes used for filenames have been removed.
  • An issue related to pasting file lists from the clipboard when using the FreeRDP client has been fixed

Special thanks to @tsz8899 for raising the original issue and working with the team on resolving it.

Replace the 256 byte buffer used for names in the XFS filesystem with a
dynamically allocated buffer.

The define XFS_MAXFILENAMELEN which used to be 255 has been retained,
but bumped to 1023. This value is no longer used for long-lived
allocations, but is used in chansrv_fuse.c for maintaining state
information for in-fligh I/O requests.

(cherry picked from commit d8b5435)
The limit of 256 characters for clipboard files is limiting for
many Asian locales, particularly as '%xx' notation is used to
communicate bytes with bit 7 set.

(cherry picked from commit a902282)
This commit ensures that filenames up to the maximum size supported
by our xfs can be supported.

(cherry picked from commit c3f7eec)
The routine clipboard_get_files() parses a potentially long string,
and copies portions of it into a temporary buffer. This buffer is then
passed to clipboard_get_file() as pointer + length;

The buffer is inadequately sized for very long filenames which may
approach XFS_MAXFILENAMELEN in length. This can cause chansrv to fail
when the user copies such filenames.

It turns out the buffer is unnecessary, as the filenames can be
passed directly into clipboard_get_file() from the source string,
using pointer + length. This avoids the length limitation entirely.

(cherry picked from commit 34b5582)
When used with a FreeRDP client on Linux, a file copy operation from
the clipboard detects end-of-file by a read returning 0 bytes. This is
currently marked as an error.

It is assumed that mstsc.exe detects end-of-file in another way, which
is why this has not been found before.

(cherry picked from commit 0f6e731)
Copy link
Member

@metalefty metalefty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Merge at your convenience.

@matt335672 matt335672 merged commit 82bec9d into neutrinolabs:v0.10 Aug 6, 2024
13 checks passed
@matt335672 matt335672 deleted the v0_10_chansrv_clip_fixes branch August 6, 2024 09:37
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.

2 participants