clipDataId is an optional field of CLIPRDR_FILECONTENTS_REQUEST.
The client should not send it to the server without sending a prior
CLIPRDR_LOCK_CLIPDATA request. The reverse is true as well: the
server should not include these additional 4 bytes without locking
the file in question.
The value zero is a valid ID, it cannot be used as a sentinel value.
Introduce a separate flag to tell whether the clipDataId has been set
and can be relied upon.
Also fix formatting. These stupid line breaks have negative impact on
readability, and the lines do fit into the 100 column limit either way.
To handle a new format we should first be able to transform the format
name from the local clipboard owner into its remote representation. In
our case this will be trasforming the "text/uri-list" target into the
"FileGroupDescriptorW" named format.
Add CB_FORMAT_TEXTURILIST to identify the local format by its ID during
the data conversion step. This numeric ID has nothing to do with the ID
which will be sent to server. It's a bit weird, but that's how XFreeRDP
works.
After that add a new client format with this ID and appropriate local
and remote format names (in atom and formatName fields respectively).
Do this only if wClipboard actually supports "text/uri-list" format.
(It could fail to initialize the local file subsystem, in which case
it will fail all file-related requests and there would be no point in
advertising the file format support in the first place.)
Finally, handle the actual format data request for a new named format
in xf_cliprdr_process_requested_data(). Remember to convert the
FILEDESCRIPTOR array we receive from wClipboard into the
CLIPRDR_FILELIST expected by the server. Also take care to not leak
memory during this conversion.
Note that this handles only the CLIPRDR_FORMAT_DATA_REQUEST. The server
is still not able to retrieve the file content as this is done via a
separate request-reply sequence.
The format is described in MS-RDPECLIP 2.2.5.2.3 Packed File List
(CLIPRDR_FILELIST). These functions handle conversion between the
on-the-wire data from cliprdr and arrays of FILEDESCRIPTOR structs.
FILETIME handling is a bit wacky, but that's what we currently have.
The flags are defined by MS-RDPECLIP 2.2.5.2.3.1 File Descriptor
(CLIPRDR_FILEDESCRIPTOR) as well as by 'File Attribute Constants'
in WinAPI reference [1].
The idea is to delegate FILEDESCRIPTOR format processing to WinPR
instead of cliprdr channel, so move the struct definition there. The
definition used by cliprdr protocol is identical but with some fields
treated as reserved.
The defintions are placed into <winpr/shell.h> as FileGroupDescriptorW
is a shell clipboard format.
Also remove the definition of CLIPRDR_FILELIST. The clients would be
using WinPR to handle the file clipping, so CLIPRDR_FILELIST does not
have to be handled explicitly. The clients will have serialization and
deserialization functions to handle CLIPRDR_FILELIST.
[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/gg258117(v=vs.85).aspx
Global static variables do not work, if more than one instance
of an RDP client is running in the same process space.
Removed the varaibles where possible and replaced them with
thread local storage where necessary.
Not use sizeof on packet memory structure for stream length check/estimating and use number directly.
Most of the packet size could be obviously calculated/verified from code and comments in same function.
Macro is defined for those were referenced multiple times.
1. Fix stream leak in rdpgfx
2. Make src data const in zgfx. Harden zgfx to be independent to byte order
3. Fix written bytes return value in channel write
4. Add check for return value in shadow_client.c
5. Add gfx callback to send surface command with frame marker pdu.
6. Check remain length for recv subroutine
7. Fix compile errors
The rdpContext gets an event which will
get set if an error occoured in a channel.
If a thread or a void callback has to report an
error it will get signaled by this system.
Fixes clang compiler warning:
"warning: the value of the size argument in 'strncat' is too large,
might lead to a buffer overflow [-Wstrncat-size]"
strncat requires an extra byte for '\0' so dest needs to have a size of
n+1
