The descriptor now carries FD_FILESIZE only when the size was actually read,
which leaves both size fields at zero for an entry where it was not. The
non-stream FILECONTENTS_SIZE handler passed those fields straight back, so a
receiver asking about such an entry would be told it is empty and would write a
zero-length file without any error. The previous code returned whatever
GetFileSize() had left behind, which for a failure is INVALID_FILE_SIZE -- also
wrong, but wrong loudly.
Answer only when the descriptor has a size, and fail the request otherwise. The
receiver then fails the paste instead of completing it with an empty file, which
is the same class of outcome the old code produced for that entry.
The IStream_Stat path is unchanged; it already answers from the stream.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
Pasting files from a Windows peer got slower with the number of files and
then stopped working, while the total size made no difference: one 32 MB
file pasted at once, 45 small files took seconds, and 50 small files
totalling 8.3 MB left the shell spinning and copied nothing.
The sender never set FD_FILESIZE, although it had already read the size and
filled nFileSizeLow/nFileSizeHigh. Without that flag the receiver cannot
trust those fields, so CliprdrStream_New() asks for the size of each file
with its own FILECONTENTS_SIZE request and blocks on the reply for up to
CLIPBOARD_RESPONSE_WAIT_TIMEOUT_SECS. Those streams are all built up front,
in the loop that answers the shell's request for the file group descriptor,
so the round trips run one after another inside IDataObject::GetData() and
the shell waits for every one of them before the paste can begin. The cost
is therefore per file, not per byte, which is what the reports describe.
The size is now declared, and only when it is known: GetFileSizeEx() replaces
GetFileSize(), whose INVALID_FILE_SIZE return cannot be told from a genuine
4GB-1 file without GetLastError(), and directories are skipped because the
handle opened with FILE_FLAG_BACKUP_SEMANTICS above is not a file handle.
A regular file whose size cannot be read is rejected instead of publishing an
ambiguous zero size. This is required because the Unix receiver currently
consumes the descriptor size fields regardless of FD_FILESIZE for
compatibility with older Windows senders.
Upstream FreeRDP, which this file comes from, sets FD_FILESIZE here. It has
been commented out in our copy since the file was first added in 6672087f7,
with no recorded reason; the "for compatibility" note above it was written
later, in 55005f812, about code that already looked this way. The Unix
receiver carries the other half of the same workaround in filetype.rs, where
the size is trusted whether or not the flag is set, explicitly "for
compatibility with Windows".
This is a sender-side fix: the paste gets faster once the machine the files
come from runs it, whichever version does the pasting.
Fixes#16238
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
* add the base crate and repoint the moved modules at it
`libs/base` (crate `base`) takes the parts of hbb_common that only this app
uses: `fs`, `platform`, `keyboard`, `message.proto`, and 145 of the 177
`config::keys` constants. hbb_common keeps what the server names, and the 32
keys it reads itself are re-exported from `base::config::keys` so call sites
still see the full set through one path.
Sources move verbatim. The only edits inside them are `crate::` prefixes that
now have to say `hbb_common::`; `keyboard.rs` and `platform/windows.rs` are
byte-identical. The crate stays on edition 2018, the edition the moved code was
written under. `log`, `lazy_static` and `anyhow` become direct dependencies so
the bare paths in that code resolve exactly as before, and its winapi features
are spelled out rather than left to feature unification.
Two call sites outside Rust and Cargo had to follow the move: the Android
protobuf source dir, which still pointed at hbb_common/protos for message.proto,
and the three AGENTS.md entries that named hbb_common for options, protos and
file transfer.
`scrap`'s `drm` feature now forwards to `base/wayland_probe`. Left pointing at
hbb_common it would still have compiled, silently dropping the Wayland
socket-probe fallback, so that forward is verified by a build with and without
the feature.
`config::keys` carries a test asserting its names stay disjoint from the ones
hbb_common kept: the glob re-export and the local constants share a namespace,
and Rust prefers the local item silently, so a name added to both sides would
otherwise let client and server disagree with no diagnostic.
Verified: macOS and Linux, debug and release, `--all-targets`; the 177 key
constants diffed name-for-name and value-for-value; the generated protobuf types
compared before and after; every `#[cfg]` gate on a moved import checked against
its original; and every file that was `rustfmt`-clean before this change still
is, compared against master file by file. Windows is checked by inspection only
-- it cannot be compiled here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
* one `use` per crate, and write the rule down
`fs.rs` came out of the move with two ungated `use hbb_common::` statements,
because the original single `use crate::{...}` had to give up `message_proto`
to the new crate and the rest was left in a second block. Fold it back into one.
A scan of the whole tree for the same shape finds nothing else: every other file
with more than one top-level `use base::` or `use hbb_common::` is split by a
`#[cfg]` that does not cover the whole block, or by `pub use` next to `use`.
Those are the cases that cannot merge, so AGENTS.md now states both the rule and
the exemption.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* harden wf_cliprdr.c
* fix copilot review
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* fix review
* fix review
* condense hardening comments, fix style in wf_cliprdr.c
Comment-only cleanup of the review-justification comments; also move
the mutex wait result declaration to the top of the block and fix
continuation-line indentation. No behavior change.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* add invariant tests for file contents request/response hardening
Cover the zeroed optional request fields, stream ID filtering,
oversized/NULL response rejection and the zero-byte EOF path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* address copilot review findings in wf_cliprdr.c
- Reject a negative FILECONTENTS_SIZE result: m_lSize is unsigned, so a
negative value became a huge bogus stream size that keeps reads going.
- Use a unique per-stream counter as the CLIPRDR streamId instead of a
truncated IStream pointer, which could collide or be reused after free
(and leaked heap addresses to the peer).
- Add req_f_request_mutex to serialize whole file-contents request/response
cycles, enforcing the previously assumed one-outstanding-request
invariant when multiple streams are read concurrently. Bounded acquire
so a wedged request fails the read instead of hanging a consumer.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* serialize file-contents request state and poison streams after timeout
- Extract lock_mutex() for the WAIT_OBJECT_0/WAIT_ABANDONED idiom shared by
take_req_fdata, the request-serialization acquire, and the response handler.
- Collapse the acquire/send/take/release cycle into
cliprdr_request_filecontents_sync(), used by CliprdrStream_Read and the size
probe in CliprdrStream_New.
- Publish req_f_stream_id_expected/req_f_size_requested under req_f_mutex in the
sender and read them under the same lock in the response handler, removing the
cross-thread data race on those fields.
- Poison a stream (m_failed) after a request fails/times out, so a late response
carrying a previous offset's bytes cannot satisfy a later same-stream read.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* key the responder stream cache on connID as well as streamId
Per-stream ids restart from 1 in each peer process, so two connections can
emit the same streamId. The process-static pStreamStc cache keyed only on
streamId could then serve one peer the IStream cached for another peer (a
different file), silently returning wrong-file bytes. Add connID to the key.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* harden the format-data path against late/duplicate responses
The format-data rendezvous had the same single-slot race the file-contents
path just fixed: the channel thread rewrote clipboard->hmem with no lock while
explorer-thread consumers read/freed it, nothing serialized concurrent
requests, and no flag told an expected response from a stray one.
- Add format_request_mutex (serializes the whole request/response cycle) and
hmem_mutex (guards the hmem hand-off and formatDataRespExpected).
- cliprdr_send_data_request now takes ownership of the response buffer under
hmem_mutex and returns it to the caller, so a later response cannot touch a
buffer a consumer is using. All three consumers (GetData, WM_RENDERFORMAT,
DELAYED_RENDERING) and the WM_CLIPBOARDUPDATE cleanup use the returned/taken
handle instead of the shared slot.
- The response handler drops any response arriving while formatDataRespExpected
is clear (late/duplicate/unsolicited), consumes the flag on the first
response, and no longer dereferences a NULL clipboard in the SetEvent path.
Pre-existing issue, not introduced by this branch; generalizes the
file-contents hardening to the format-data path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* remove the dedicated wf-cliprdr CI workflow
Drop .github/workflows/wf-cliprdr-ci.yml on this branch as requested.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* remove wf-cliprdr invariant tests
Drop tests/test_invariant_wf_cliprdr.c on this branch as requested.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor and simplify, remove mutex which is dangeours
* fix copilot false report
* fix review
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* fix(clipboard): make CLIPRDR format-map growth checked
The Windows CLIPRDR format-list handler relies on map_ensure_capacity()
while processing peer-provided formats. The previous helper only attempted
growth: if realloc() failed, it returned silently and the caller continued
processing. A later iteration could then index past the allocated
format_mappings array.
Make format-map growth a checked operation. The handler now validates the
peer-provided format count, ensures the mapping array is large enough before
writing entries, and aborts processing if growth fails. Newly allocated slots
are zeroed so existing cleanup can safely run after partial processing.
Also bound remote format names before measuring/converting them. The chosen
limits follow Windows clipboard/atom constraints:
- registered clipboard format IDs use 0xC000..0xFFFF
- string atom names are limited to 255 bytes
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(clipboard): reject invalid remote format-list entries
Signed-off-by: fufesou <linlong1266@gmail.com>
---------
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(clipboard): clean up stale Linux FUSE mounts
Recover Linux file clipboard FUSE mount points before remounting and stop treating a cached
context as valid when the mount has already gone away.
This fixes the desktop file manager copy failure that shows dialogs such as
"Error while copying a" and "There was an error copying the file into xxx".
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(clipboard): fuse, reduce dups
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix: clear Linux file clipboard before unmounting FUSE
Ensure Linux client teardown clears RustDesk file clipboard URLs while
the FUSE context is still available. Also prefer fusermount before
umount to avoid noisy unprivileged teardown attempts.
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(clipboard): return and log errors
Signed-off-by: fufesou <linlong1266@gmail.com>
---------
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(clipboard): unix, refresh cached file size/mtime on re-copy
sync_files() deduped re-copies by path string only, so editing a file
and re-copying it (same path) skipped refreshing the cached size/mtime
and the file-group descriptor; the peer then received the file
truncated to the old cached size (silent corruption for PDF/zip/pptx).
Widen the early-return guard to also compare a top-level (size, mtime)
fingerprint and to always rebuild when a directory is selected. The
Windows wf_cliprdr.c path re-stats per request and is unaffected.
Signed-off-by: RAIT-09 <51452399+RAIT-09@users.noreply.github.com>
* opt(clipboard): unix, compute file fingerprint once and pass into sync_files
fingerprint() was computed before taking the CLIP_FILES lock and then
recomputed inside ClipFiles::sync_files under the lock. Pass the precomputed
value in so the top-level stat runs once and outside the critical section.
No behavior change.
Signed-off-by: RAIT-09 <51452399+RAIT-09@users.noreply.github.com>
---------
Signed-off-by: RAIT-09 <51452399+RAIT-09@users.noreply.github.com>
* docs: fix typos in documentation and code comments
- Fix 'seperated' -> 'separated' in remote_input.dart
- Fix 'seperators' -> 'separators' in fuse/cs.rs
- Update outdated 'OSX' -> 'macOS' in virtual display README
Signed-off-by: pallab-js <sonowalpallabjyoti@gmail.com>
* impl(cm): implement change_theme and change_language callbacks
These callbacks were previously empty TODO stubs.
Now they properly invoke the Sciter UI handlers to notify
the UI when theme or language changes occur.
Signed-off-by: pallab-js <sonowalpallabjyoti@gmail.com>
---------
Signed-off-by: pallab-js <sonowalpallabjyoti@gmail.com>
* fix: windows, empty file clipboard on disconn
Signed-off-by: fufesou <linlong1266@gmail.com>
* refact: Don't send files copied before the conn
Signed-off-by: fufesou <linlong1266@gmail.com>
* refact: windows, file clipboard
Empty clipboard if no `Ctrl+C` is pressed, but
`CliprdrDataObject_GetData()` is called.
`CliprdrDataObject_GetData()` is only called in the clipboard object set
by RustDesk.
Signed-off-by: fufesou <linlong1266@gmail.com>
---------
Signed-off-by: fufesou <linlong1266@gmail.com>
1. Return the result of `wait_response_event()` in
`cliprdr_send_format_list()`
2. Add recv flags to avoid waiting a long time.
Signed-off-by: fufesou <linlong1266@gmail.com>
