* test: remove tests that do not pin user-visible behavior
Apply the AGENTS.md test rules to the existing Rust and Flutter suites.
A test is kept when it is the only coverage of user- or API-visible
behavior, the regression test of a reported or fixed bug, a security
boundary (one test per rejection class), or a check against an external
reference. Tests that assert private state or the order of internal
steps, pin review-round corner cases, or repeat what a kept test already
covers are removed.
Rust: 679 -> 298 tests. Dart: 118 -> 45 tests.
Test-only helpers left without callers go with them
(applyLastOnlineStateForTesting, terminalKeyboardRowWidth,
debugBufferedInputCount, tokio's test-util dev feature), and cfg gates
and visibility that existed only for the deleted tests are narrowed.
Runtime behavior is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R
* test: keep tests that pin security and user-visible behavior
Restore six tests that review showed are the only coverage of their
behavior:
- update metadata rejects an artifact file name with path components;
- ICE candidates from another session are dropped;
- KCP delivers every multi-segment frame queued before a close;
- set_files rejects an empty name in a multi-file transfer;
- a lopsided elongated cursor keeps its centre hotspot (#16242);
- toggling Show hidden during a pending same-path read issues a new read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R
* test: keep offline update and key-exchange downgrade rejections
Restore three tests that are the only coverage of their rejection class:
- offline update metadata rejects a signed artifact with an http or
credential-bearing URL;
- offline verification rejects a renamed local file and a version that
does not match the release;
- a key-exchange pick lowered in transit leaves both sides unable to
decrypt, so a v0 fallback after a failed v1 decrypt cannot pass
unnoticed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R
* test: keep the decomposed-grapheme and reconnect-cancel tests
Each catches a plausible wrong change that passes every kept test:
mapping the first scalar under a locked Ctrl turns é into \x05,
and a reconnect that does not fail pending reads leaves them hanging
until the 30 s timeout.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A directory pasted from Windows with FILE_ATTRIBUTE_READONLY or
FILE_ATTRIBUTE_HIDDEN (Git for Windows hides `.git`) was given mode 0444 or
0400 in the FUSE list, because the read-only and hidden branches came before
the directory branch. Without `x` the directory cannot be entered once a
mode-preserving copy lands it on disk. Windows does not restrict access to a
directory for either attribute, so give every directory 0755, as a plain one
already gets.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
After serving a request for file N, `serve_file_contents` preloads the
next non-directory file with `load_handle()?`. When that file can no
longer be opened (deleted or renamed after the copy, or unreadable), its
error replaced N's reply, so every size and range request for N failed
although N itself is intact.
Keep the preload best-effort. Its failure is logged at trace, because it
can fire on every request for N, and N+1's own request still reports the
error.
Signed-off-by: chlee <sourcehatchery@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`LDAP_EPOCH_DELTA`, the offset from the FILETIME epoch (1601-01-01) to
the Unix epoch in 100 ns units, was 116444772610000000. The real offset
is 116444736000000000 (11644473600 s), so the old value is 3661 s
(1h01m01s) too large.
Unix peers encode and decode with the same constant, so the error cancels
between them, but Windows sends and reads real FILETIMEs: files copied
from Windows got a modified time 1h01m01s too early on Linux and macOS,
and files copied from Linux or macOS were sent one 1h01m01s too late.
Signed-off-by: chlee <sourcehatchery@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(macos): clear Finder progress after clipboard transfers
Signed-off-by: fufesou <linlong1266@gmail.com>
* test(macos): cover single-response clipboard completion
Verify progress completion, handle cleanup, and finalized file contents.
Move function-only Finder imports into progress helpers.
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(macos): unpublish clipboard progress before renaming
Complete and unpublish NSProgress before the final file rename to avoid
stale Finder and Dock progress indicators.
Signed-off-by: fufesou <linlong1266@gmail.com>
* chore: add ref
Signed-off-by: fufesou <linlong1266@gmail.com>
---------
Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(clipboard): unix file server, bound range reads
The Range request fields nPositionLow and cbRequested are UINT32s carried
in i32 fields, but were sign-extended to u64. A negative cbRequested
became a near-u64::MAX length, `offset + length` wrapped past the clamp,
and the server tried to allocate a u64::MAX buffer, aborting the process.
Sign-extending nPositionLow also rejected offsets whose low word is
>= 2 GiB, breaking reads past 2 GiB in large files.
- decode nPositionLow and cbRequested as u32
- clamp with `length > file.size - offset` (offset <= size is checked above)
- allocate the read buffer fallibly and return an error instead of aborting
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(enigo): win, scale absolute mouse moves without overflow
mouse_move_to multiplied the peer-supplied coordinate by 65535 in i32,
which overflows for large values, and divided by the virtual screen size,
which panics if the metrics come back as 0. Scale in i64, clamp to i32,
and skip the move when the virtual screen size is unavailable. Results
for inputs that did not overflow are unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* docs(agents): avoid unthrottled high-frequency debug logs
Debug output is written to the log file, so per-packet / per-event log sites
must use trace or hbb_common's throttled_log!.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): unix file server, reject range reads over the frame limit
A response larger than MAX_FRAME_LENGTH (1 GiB) cannot be encoded for
sending, yet the server allocated and read it first, then failed the send.
Reject such requests before allocating, so a peer can no longer make the
server allocate more than 1 GiB per request. Requests that work today are
unaffected.
Drop the extra allocation-failure log; the caller already logs the error.
Tests cover the wire decoding through read_file_contents (negative
cbRequested, nPositionLow past 2 GiB) and the frame-limit rejection. Tests
that use the global CLIP_FILES now take a shared lock.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): keep file transfers on the file list they started from
A file-contents request names a file only by its index, and the side that
owns the files resolved it against whatever it held at that moment. On
Windows 10+ Explorer's clipboard also offers FileContents, which the owner
re-read from the live clipboard for every chunk, so copying another file
mid-transfer spliced the new file into the one being pasted (#16332). A
second paste, or another connection's paste, replaced the list the same
way, and on macOS/Linux sync_files replaced CLIP_FILES on every host copy.
Each request now names its list in the existing clip_data_id field: an
FNV-1a hash of the file-descriptor PDU, which both sides already hold.
Owners keep the last 4 lists they sent and serve a request from the list
it names; an unknown id fails instead of reading another file. Peers that
send no id read the list last sent to their connection, and a Windows
owner stops reading the live clipboard once it has changed since the list
was built.
Tests cover a host copy and a second paste during a transfer, a list id
sent to another connection, and the hash's reference vectors.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): unix file server, cap a single range read at 16 MiB
A peer could still make the server allocate and read up to the 1 GiB frame
limit per request. Cap the data a single range read returns at 16 MiB. The
read is clamped to the rest of the file first, and a larger one is refused
rather than shortened: a short response reads as end of file to IStream
callers on Windows and would silently truncate the copy.
macOS requests 4 MiB per range (BLOCK_SIZE) and FUSE reads are smaller. A
Windows client forwards the application's IStream::Read size, so only an
application reading more than 16 MiB in one call is affected.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(enigo): win, warn (throttled) when a mouse move is skipped
A missing virtual screen size is a fault that should show up in a user's
log, but mouse_move_to runs per input event. Log it at warn at most once a
minute via throttled_log! instead of at trace.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): review fixes for the file lists kept per transfer
unix owner:
- A retired list closes its files and 8 MiB read buffers; they reopen,
from offset 0, on the next read.
- The new list is built aside and swapped in only on success, so a failed
rebuild leaves the current list in place.
- A rebuild with an unchanged id keeps its peers on the new list instead of
retiring a duplicate, so re-copying a directory no longer pushes out a
list that a transfer is still reading.
Windows:
- One served-list slot per list, recording every connection it was sent
to, so pastes of the same list do not use up slots.
- A request for an earlier list is served before OleGetClipboard, so a busy
clipboard cannot fail it.
- An IStream read over 16 MiB is split into requests the unix file server
accepts. Reads up to 16 MiB take the unchanged path.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): give each copied file list its own id
The list id hashed only the descriptors, so two copies with identical
names, sizes and times (the same file in two folders) shared an id and a
transfer could read the other copy's files. Each owner now writes a random
nonce into the first descriptor's clsid, inside the reserved bytes every
peer skips; no owner sets FD_CLSID. The paste side hashes what it received,
so it needs no change, and older peers ignore the bytes. Re-sending the same
paths with the same descriptors keeps the nonce, and the id.
Windows owner:
- Serve a request from its list before the ownership check when the list is
no longer current or the host clipboard now holds files from a peer, so
another controller copying onto the host no longer fails in-flight
transfers. Only lists sent to that connection are served.
- Evict the list sent least recently instead of in insertion order.
unix owner: take everything from the crate in one use block.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard,enigo): bound served-list reads, clamp absolute moves
wf_cliprdr: the served-list branch runs before the ownership check, yet it
allocated the peer's cbRequested (up to 4 GiB) before looking the list up.
Accept only FILECONTENTS_SIZE or a range of at most 16 MiB there, which is
all that clients sending an id ever request, and fail anything else before
allocating.
enigo: clamp the scaled absolute coordinate to 0..=65535, the range
MOUSEEVENTF_ABSOLUTE takes, instead of to the i32 range. Coordinates on the
virtual desktop give the same result as before; off-desktop ones now land on
its edge.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): keep a file list while it is being read, throttle read errors
A unix paste side fetches every new file list as soon as the host copies,
so each copy retires the previous list, and four copies during one long
transfer evicted the list it was still reading. A kept list that serves a
read now becomes the most recent (unix: back of the retired queue, Windows:
last_served), so the next eviction takes a list nobody is reading.
A failed file-contents read logged an error per request, and peers can now
trigger new ones (an unknown list id, an over-limit range). Log it through
throttled_log! instead.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): unix, keep retired lists in the order they were sent
A peer that sends no list id is served the list last sent to its
connection, found by searching the retired queue from the back. That only
holds while the queue stays in retirement order, which is the order lists
were sent. The previous commit moved a list to the back on every read, so
another connection reading an older list could make a peer's next chunk
come from that list: a transfer of B continued with A's bytes.
Keep the queue in retirement order and track recency in a separate
last_used stamp, set on retirement and on each read. A full queue evicts the
list with the lowest stamp, so a list still being read is kept.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): unix, keep files being read open when their list is retired
Retiring a list closed every file handle, so the next read of a file part-way
through reopened it by path. If that path had been replaced meanwhile (an
editor saving over it), the rest of the transfer came from the replacement:
AAAABBBB arrived as AAAADDDD. Close only files that are not being read, such
as the preloaded next file; a file part-way through keeps its handle and
offset, and so its identity.
Tests read two files of one list alternately, retire the list, replace both
paths by rename, and check each file continues with its original bytes.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): cap Windows ranges, expire idle kept lists, check file identity
Windows owner: refuse every FILECONTENTS_RANGE over 16 MiB before
allocating. Only the served-list branch was capped; requests without an id
still allocated whatever the peer asked for, up to 4 GiB.
Both owners: a kept (retired / non-current) file list that nobody has read
for 5 minutes is dropped, with its open files; its transfer is over or its
peer gone. The current list never expires, as before. On Windows, reads of
the current list through the existing path now also refresh its kept copy,
so a long transfer does not lose its list once a newer one is sent.
Windows owner: old-list reads compare the file's size and last-write time
with the descriptor that was sent, on the handle they read from, and fail
on a mismatch instead of reading whatever file now has that path.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* test(clipboard): unix, check list expiry without backdating an Instant
an_idle_retired_list_expires backdated a timestamp with
Instant::now().checked_sub(TTL + 1s), which is None while the monotonic
clock is under about five minutes, as on a freshly booted CI machine; the
list then never expired and the test failed. expire_retired now takes the
current time, and the test passes a later one instead. Callers pass
Instant::now(), so behavior is unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix(clipboard): drop read-time refresh, idle expiry and rebuild reuse; tighten checks
Remove the read-time recency and the 5-minute idle expiry on both owners,
and the unix reuse of an unchanged rebuild (has_same_files). They covered
corner cases, added state, and each brought regressions of its own. Kept
lists are again evicted oldest first (unix) or least recently sent
(Windows), 4 at most; a transfer that outlives 4 newer lists fails cleanly.
Windows: serve kept lists after the existing ownership check again, so a
request carrying a list id no longer bypasses it while the host clipboard
holds files from another session. Refuse request types other than size or
range before allocating.
unix: a retired list's file must still match the size and modified time it
was listed with, checked on the handle the read uses; a file replaced at
its path before its read now fails instead of being served.
Tests: drop the four tests of the removed behavior, add
a_retired_list_refuses_a_file_replaced_before_its_read.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* docs(agents): handle corner cases raised in review with small fixes or docs
A refactor added to cover a corner case rarely converges: new counters,
timestamps and expiry rules interact with state existing code relies on,
and the next review round finds the problems they introduced. Fix a corner
case when the fix is a few lines with no new state; otherwise document it
as a known limit, and ask before anything larger.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* 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>
