mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-09-18 10:21:03 +03:00
bc358ceb1f
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 in6672087f7, with no recorded reason; the "for compatibility" note above it was written later, in55005f812, 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