Files
FreeRDP/winpr/libwinpr/clipboard/synthetic_file.c

1250 lines
34 KiB
C
Raw Normal View History

/**
* WinPR: Windows Portable Runtime
* Clipboard Functions: POSIX file handling
*
* Copyright 2017 Alexei Lozovsky <a.lozovsky@gmail.com>
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
2022-02-16 10:08:00 +01:00
#include <winpr/config.h>
2023-10-11 17:03:39 +02:00
#include <winpr/platform.h>
2023-10-11 17:03:39 +02:00
WINPR_PRAGMA_DIAG_PUSH
WINPR_PRAGMA_DIAG_IGNORED_RESERVED_ID_MACRO
WINPR_PRAGMA_DIAG_IGNORED_UNUSED_MACRO
2021-09-08 15:37:45 +02:00
#define _FILE_OFFSET_BITS 64 // NOLINT(bugprone-reserved-identifier,cert-dcl37-c,cert-dcl51-cpp)
2021-09-08 15:37:45 +02:00
2023-10-11 17:03:39 +02:00
WINPR_PRAGMA_DIAG_POP
2021-09-08 15:37:45 +02:00
#include <errno.h>
#include <winpr/wtypes.h>
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
2018-08-24 13:49:19 +02:00
#include <winpr/crt.h>
#include <winpr/clipboard.h>
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
#include <winpr/collections.h>
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
#include <winpr/file.h>
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
#include <winpr/shell.h>
#include <winpr/string.h>
#include <winpr/wlog.h>
#include <winpr/path.h>
#include <winpr/print.h>
#include "clipboard.h"
#include "synthetic_file.h"
#include "../log.h"
#define TAG WINPR_TAG("clipboard.synthetic.file")
2023-02-21 15:13:07 +01:00
static const char* mime_uri_list = "text/uri-list";
static const char* mime_FileGroupDescriptorW = "FileGroupDescriptorW";
2023-02-21 15:46:21 +01:00
static const char* mime_gnome_copied_files = "x-special/gnome-copied-files";
static const char* mime_mate_copied_files = "x-special/mate-copied-files";
struct synthetic_file
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
{
WCHAR* local_name;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
WCHAR* remote_name;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
HANDLE fd;
INT64 offset;
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
};
2022-10-27 14:13:00 +02:00
void free_synthetic_file(struct synthetic_file* file);
static struct synthetic_file* make_synthetic_file(const WCHAR* local_name, const WCHAR* remote_name)
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
{
2026-02-26 14:32:50 +01:00
struct synthetic_file* file = nullptr;
WIN32_FIND_DATAW fd = WINPR_C_ARRAY_INIT;
2026-02-26 14:32:50 +01:00
HANDLE hFind = nullptr;
WINPR_ASSERT(local_name);
WINPR_ASSERT(remote_name);
hFind = FindFirstFileW(local_name, &fd);
if (INVALID_HANDLE_VALUE == hFind)
{
WLog_ERR(TAG, "FindFirstFile failed (%" PRIu32 ")", GetLastError());
2026-02-26 14:32:50 +01:00
return nullptr;
}
FindClose(hFind);
2017-11-14 13:57:00 +01:00
file = calloc(1, sizeof(*file));
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
if (!file)
2026-02-26 14:32:50 +01:00
return nullptr;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
file->fd = INVALID_HANDLE_VALUE;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
file->offset = 0;
file->local_name = _wcsdup(local_name);
if (!file->local_name)
goto fail;
file->remote_name = _wcsdup(remote_name);
if (!file->remote_name)
goto fail;
2026-01-08 10:32:31 +01:00
{
const size_t len = _wcslen(file->remote_name);
if (S_OK != PathCchConvertStyleW(file->remote_name, len, PATH_STYLE_WINDOWS))
goto fail;
2026-01-08 10:32:31 +01:00
}
file->dwFileAttributes = fd.dwFileAttributes;
file->ftCreationTime = fd.ftCreationTime;
file->ftLastWriteTime = fd.ftLastWriteTime;
file->ftLastAccessTime = fd.ftLastAccessTime;
file->nFileSizeHigh = fd.nFileSizeHigh;
file->nFileSizeLow = fd.nFileSizeLow;
return file;
fail:
2022-10-27 14:13:00 +02:00
free_synthetic_file(file);
2026-02-26 14:32:50 +01:00
return nullptr;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
}
static UINT synthetic_file_read_close(struct synthetic_file* file, BOOL force);
2022-10-27 14:13:00 +02:00
void free_synthetic_file(struct synthetic_file* file)
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
{
if (!file)
return;
synthetic_file_read_close(file, TRUE);
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
free(file->local_name);
free(file->remote_name);
free(file);
}
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
/*
* Note that the function converts a single file name component,
* it does not take care of component separators.
*/
static WCHAR* convert_local_name_component_to_remote(wClipboard* clipboard, const WCHAR* local_name)
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
{
wClipboardDelegate* delegate = ClipboardGetDelegate(clipboard);
2026-02-26 14:32:50 +01:00
WCHAR* remote_name = nullptr;
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
WINPR_ASSERT(delegate);
remote_name = _wcsdup(local_name);
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
/*
* Some file names are not valid on Windows. Check for these now
* so that we won't get ourselves into a trouble later as such names
* are known to crash some Windows shells when pasted via clipboard.
*
* The IsFileNameComponentValid callback can be overridden by the API
* user, if it is known, that the connected peer is not on the
* Windows platform.
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
*/
if (!delegate->IsFileNameComponentValid(remote_name))
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
{
char name[MAX_PATH] = WINPR_C_ARRAY_INIT;
ConvertWCharToUtf8(local_name, name, sizeof(name) - 1);
WLog_ERR(TAG, "invalid file name component: %s", name);
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
goto error;
}
return remote_name;
error:
free(remote_name);
2026-02-26 14:32:50 +01:00
return nullptr;
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
}
static WCHAR* concat_file_name(const WCHAR* dir, const WCHAR* file)
{
size_t len_dir = 0;
size_t len_file = 0;
const WCHAR slash = '/';
2026-02-26 14:32:50 +01:00
WCHAR* buffer = nullptr;
WINPR_ASSERT(dir);
WINPR_ASSERT(file);
len_dir = _wcslen(dir);
len_file = _wcslen(file);
buffer = calloc(len_dir + 1 + len_file + 2, sizeof(WCHAR));
2017-11-14 13:57:00 +01:00
if (!buffer)
2026-02-26 14:32:50 +01:00
return nullptr;
memcpy(buffer, dir, len_dir * sizeof(WCHAR));
buffer[len_dir] = slash;
memcpy(buffer + len_dir + 1, file, len_file * sizeof(WCHAR));
return buffer;
}
static BOOL add_file_to_list(wClipboard* clipboard, const WCHAR* local_name,
const WCHAR* remote_name, wArrayList* files);
static BOOL add_directory_entry_to_list(wClipboard* clipboard, const WCHAR* local_dir_name,
const WCHAR* remote_dir_name,
const LPWIN32_FIND_DATAW pFileData, wArrayList* files)
{
BOOL result = FALSE;
2026-02-26 14:32:50 +01:00
WCHAR* local_name = nullptr;
WCHAR* remote_name = nullptr;
WCHAR* remote_base_name = nullptr;
WCHAR dotbuffer[6] = WINPR_C_ARRAY_INIT;
WCHAR dotdotbuffer[6] = WINPR_C_ARRAY_INIT;
const WCHAR* dot = InitializeConstWCharFromUtf8(".", dotbuffer, ARRAYSIZE(dotbuffer));
const WCHAR* dotdot = InitializeConstWCharFromUtf8("..", dotdotbuffer, ARRAYSIZE(dotdotbuffer));
WINPR_ASSERT(clipboard);
WINPR_ASSERT(local_dir_name);
WINPR_ASSERT(remote_dir_name);
WINPR_ASSERT(pFileData);
WINPR_ASSERT(files);
/* Skip special directory entries. */
if ((_wcscmp(pFileData->cFileName, dot) == 0) || (_wcscmp(pFileData->cFileName, dotdot) == 0))
return TRUE;
remote_base_name = convert_local_name_component_to_remote(clipboard, pFileData->cFileName);
2017-11-14 13:57:00 +01:00
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
if (!remote_base_name)
return FALSE;
local_name = concat_file_name(local_dir_name, pFileData->cFileName);
remote_name = concat_file_name(remote_dir_name, remote_base_name);
if (local_name && remote_name)
result = add_file_to_list(clipboard, local_name, remote_name, files);
free(remote_base_name);
free(remote_name);
free(local_name);
return result;
}
static BOOL do_add_directory_contents_to_list(wClipboard* clipboard, const WCHAR* local_name,
const WCHAR* remote_name, WCHAR* namebuf,
wArrayList* files)
{
WINPR_ASSERT(clipboard);
WINPR_ASSERT(local_name);
WINPR_ASSERT(remote_name);
WINPR_ASSERT(files);
WINPR_ASSERT(namebuf);
WIN32_FIND_DATAW FindData = WINPR_C_ARRAY_INIT;
HANDLE hFind = FindFirstFileW(namebuf, &FindData);
if (INVALID_HANDLE_VALUE == hFind)
{
WLog_ERR(TAG, "FindFirstFile failed (%" PRIu32 ")", GetLastError());
return FALSE;
}
while (TRUE)
{
if (!add_directory_entry_to_list(clipboard, local_name, remote_name, &FindData, files))
{
FindClose(hFind);
return FALSE;
}
BOOL bRet = FindNextFileW(hFind, &FindData);
if (!bRet)
{
FindClose(hFind);
if (ERROR_NO_MORE_FILES == GetLastError())
return TRUE;
WLog_WARN(TAG, "FindNextFile failed (%" PRIu32 ")", GetLastError());
return FALSE;
}
}
return TRUE;
}
static BOOL add_directory_contents_to_list(wClipboard* clipboard, const WCHAR* local_name,
const WCHAR* remote_name, wArrayList* files)
{
BOOL result = FALSE;
union
{
const char* c;
const WCHAR* w;
} wildcard;
const char buffer[6] = { '/', '\0', '*', '\0', '\0', '\0' };
wildcard.c = buffer;
const size_t wildcardLen = ARRAYSIZE(buffer) / sizeof(WCHAR);
WINPR_ASSERT(clipboard);
WINPR_ASSERT(local_name);
WINPR_ASSERT(remote_name);
WINPR_ASSERT(files);
size_t len = _wcslen(local_name);
WCHAR* namebuf = calloc(len + wildcardLen, sizeof(WCHAR));
if (!namebuf)
return FALSE;
_wcsncat(namebuf, local_name, len);
_wcsncat(namebuf, wildcard.w, wildcardLen);
2017-11-14 13:57:00 +01:00
result = do_add_directory_contents_to_list(clipboard, local_name, remote_name, namebuf, files);
free(namebuf);
return result;
}
static BOOL add_file_to_list(wClipboard* clipboard, const WCHAR* local_name,
const WCHAR* remote_name, wArrayList* files)
{
2026-02-26 14:32:50 +01:00
struct synthetic_file* file = nullptr;
WINPR_ASSERT(clipboard);
WINPR_ASSERT(local_name);
WINPR_ASSERT(remote_name);
WINPR_ASSERT(files);
file = make_synthetic_file(local_name, remote_name);
2017-11-14 13:57:00 +01:00
if (!file)
return FALSE;
if (!ArrayList_Append(files, file))
{
free_synthetic_file(file);
return FALSE;
}
if (file->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
/*
* This is effectively a recursive call, but we do not track
* recursion depth, thus filesystem loops can cause a crash.
*/
if (!add_directory_contents_to_list(clipboard, local_name, remote_name, files))
return FALSE;
}
return TRUE;
}
static const WCHAR* get_basename(const WCHAR* name)
{
const WCHAR* c = name;
const WCHAR* last_name = name;
const WCHAR slash = '/';
WINPR_ASSERT(name);
while (*c++)
{
if (*c == slash)
last_name = c + 1;
}
return last_name;
}
static BOOL process_file_name(wClipboard* clipboard, const WCHAR* local_name, wArrayList* files)
{
BOOL result = FALSE;
2026-02-26 14:32:50 +01:00
const WCHAR* base_name = nullptr;
WCHAR* remote_name = nullptr;
WINPR_ASSERT(clipboard);
WINPR_ASSERT(local_name);
WINPR_ASSERT(files);
/*
* Start with the base name of the file. text/uri-list contains the
* exact files selected by the user, and we want the remote files
* to have names relative to that selection.
*/
base_name = get_basename(local_name);
remote_name = convert_local_name_component_to_remote(clipboard, base_name);
2017-11-14 13:57:00 +01:00
wClipboard: disallow Windows reserved names Another issue revealed during testing is that older Windows systems cannot handle the reserved file names well. While Windows 8 and 10 are fine (they silently abort the file transfer), using reserved names with Windows 7 can flat out crash explorer.exe or result into weird error messages like "fatal error: 0x00000000 ERROR_SUCCESS". This is not required by MS-RDPECLIP specification, but we should try to avoid this issue as not using reserved file names seems to be assumed a common sense in Windows protocols. The most convenient way to handle the issue would be on wClipboard level so that WinPR's clients do not bother with it. We should prohibit the reserved names from being used in FILEDESCRIPTOR, failing the conversion if we see such a file. POSIX subsystem (the only one at the moment) handles remote file names in two places so move the Unicode conversion and the new validation check into a separate function. The reserved file name predicate is placed into <winpr/file.h> so that it can be used in other places too. For example, other wClipboard local file subsystems will need it. (It would be really nice to enforce this check somewhere in the common code, so that the subsystems can't miss it, but other places can miss some errors thus we're doing it here, as early as possible.) The predicate acts on separate file name components rather than full file names because the backslash is a reserved character too. If we process full file names this can result in phantom directory entry in the remote file name. Not to say that handling ready-made components spares us from splitting the full file name to extract them :) The implementation is... a bit verbose, but that's fine by me. In the absence of functions for case-insensitive wide string comparison and the need to check for the [0-9] at the end of some file names this is quite readable. Thanks to FAT and NTFS for being case-insensitive and to MS-DOS for having reserved file names in the first place.
2017-04-09 02:29:52 +03:00
if (!remote_name)
return FALSE;
result = add_file_to_list(clipboard, local_name, remote_name, files);
free(remote_name);
return result;
}
static BOOL process_uri(wClipboard* clipboard, const char* uri, size_t uri_len)
{
// URI is specified by RFC 8089: https://datatracker.ietf.org/doc/html/rfc8089
BOOL result = FALSE;
2026-02-26 14:32:50 +01:00
char* name = nullptr;
WINPR_ASSERT(clipboard);
name = parse_uri_to_local_file(uri, uri_len);
if (name)
{
2026-02-26 14:32:50 +01:00
WCHAR* wname = nullptr;
/*
* Note that local file names are not actually guaranteed to be
* encoded in UTF-8. Filesystems and users can use whatever they
* want. The OS does not care, aside from special treatment of
* '\0' and '/' bytes. But we need to make some decision here.
* Assuming UTF-8 is currently the most sane thing.
*/
2026-02-26 14:32:50 +01:00
wname = ConvertUtf8ToWCharAlloc(name, nullptr);
if (wname)
result = process_file_name(clipboard, wname, clipboard->localFiles);
free(name);
free(wname);
}
return result;
}
static BOOL process_uri_list(wClipboard* clipboard, const char* data, size_t length)
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
{
const char* cur = data;
const char* lim = data + length;
WINPR_ASSERT(clipboard);
WINPR_ASSERT(data);
WLog_VRB(TAG, "processing URI list:\n%.*s", WINPR_ASSERTING_INT_CAST(int, length), data);
ArrayList_Clear(clipboard->localFiles);
/*
* The "text/uri-list" Internet Media Type is specified by RFC 2483.
*
* While the RFCs 2046 and 2483 require the lines of text/... formats
* to be terminated by CRLF sequence, be prepared for those who don't
* read the spec, use plain LFs, and don't leave the trailing CRLF.
*/
while (cur < lim)
{
BOOL comment = (*cur == '#');
const char* start = cur;
const char* stop = cur;
for (; stop < lim; stop++)
{
if (*stop == '\r')
{
if ((stop + 1 < lim) && (*(stop + 1) == '\n'))
cur = stop + 2;
else
cur = stop + 1;
2017-11-14 13:57:00 +01:00
break;
}
2017-11-14 13:57:00 +01:00
if (*stop == '\n')
{
cur = stop + 1;
break;
}
}
2017-11-14 13:57:00 +01:00
if (stop == lim)
{
if (strnlen(start, WINPR_ASSERTING_INT_CAST(size_t, stop - start)) < 1)
return TRUE;
cur = lim;
}
if (comment)
continue;
if (!process_uri(clipboard, start, WINPR_ASSERTING_INT_CAST(size_t, stop - start)))
return FALSE;
}
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
return TRUE;
}
static BOOL convert_local_file_to_filedescriptor(const struct synthetic_file* file,
2020-09-17 15:21:45 +02:00
FILEDESCRIPTORW* descriptor)
{
size_t remote_len = 0;
WINPR_ASSERT(file);
WINPR_ASSERT(descriptor);
descriptor->dwFlags = FD_ATTRIBUTES | FD_FILESIZE | FD_WRITESTIME | FD_PROGRESSUI;
if (file->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
descriptor->dwFileAttributes = FILE_ATTRIBUTE_DIRECTORY;
descriptor->nFileSizeLow = 0;
descriptor->nFileSizeHigh = 0;
}
else
{
descriptor->dwFileAttributes = FILE_ATTRIBUTE_NORMAL;
descriptor->nFileSizeLow = file->nFileSizeLow;
descriptor->nFileSizeHigh = file->nFileSizeHigh;
}
descriptor->ftLastWriteTime = file->ftLastWriteTime;
remote_len = _wcsnlen(file->remote_name, ARRAYSIZE(descriptor->cFileName));
2017-11-14 13:57:00 +01:00
if (remote_len >= ARRAYSIZE(descriptor->cFileName))
{
2019-11-06 15:24:51 +01:00
WLog_ERR(TAG, "file name too long (%" PRIuz " characters)", remote_len);
return FALSE;
}
memcpy(descriptor->cFileName, file->remote_name, remote_len * sizeof(WCHAR));
return TRUE;
}
2020-09-17 15:21:45 +02:00
static FILEDESCRIPTORW* convert_local_file_list_to_filedescriptors(wArrayList* files)
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
{
size_t count = 0;
2026-02-26 14:32:50 +01:00
FILEDESCRIPTORW* descriptors = nullptr;
count = ArrayList_Count(files);
descriptors = calloc(count, sizeof(FILEDESCRIPTORW));
2017-11-14 13:57:00 +01:00
if (!descriptors)
goto error;
for (size_t i = 0; i < count; i++)
{
const struct synthetic_file* file = ArrayList_GetItem(files, i);
if (!convert_local_file_to_filedescriptor(file, &descriptors[i]))
goto error;
}
return descriptors;
error:
free(descriptors);
2026-02-26 14:32:50 +01:00
return nullptr;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
}
static void* convert_any_uri_list_to_filedescriptors(wClipboard* clipboard,
WINPR_ATTR_UNUSED UINT32 formatId,
UINT32* pSize)
{
2026-02-26 14:32:50 +01:00
FILEDESCRIPTORW* descriptors = nullptr;
WINPR_ASSERT(clipboard);
WINPR_ASSERT(pSize);
descriptors = convert_local_file_list_to_filedescriptors(clipboard->localFiles);
*pSize = 0;
if (!descriptors)
2026-02-26 14:32:50 +01:00
return nullptr;
*pSize = (UINT32)ArrayList_Count(clipboard->localFiles) * sizeof(FILEDESCRIPTORW);
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
return descriptors;
}
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
static void* convert_uri_list_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
2019-11-06 15:24:51 +01:00
const void* data, UINT32* pSize)
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
{
const UINT32 expected = ClipboardGetFormatId(clipboard, mime_uri_list);
if (formatId != expected)
2026-02-26 14:32:50 +01:00
return nullptr;
if (!process_uri_list(clipboard, (const char*)data, *pSize))
2026-02-26 14:32:50 +01:00
return nullptr;
return convert_any_uri_list_to_filedescriptors(clipboard, formatId, pSize);
}
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
static BOOL process_files(wClipboard* clipboard, const char* data, UINT32 pSize, const char* prefix)
{
WINPR_ASSERT(prefix);
const size_t prefix_len = strlen(prefix);
WINPR_ASSERT(clipboard);
ArrayList_Clear(clipboard->localFiles);
if (!data || (pSize < prefix_len))
return FALSE;
if (strncmp(data, prefix, prefix_len) != 0)
return FALSE;
data += prefix_len;
2025-03-11 11:29:18 +01:00
if (pSize < prefix_len)
return FALSE;
pSize -= WINPR_ASSERTING_INT_CAST(uint32_t, prefix_len);
BOOL rc = FALSE;
char* copy = strndup(data, pSize);
if (!copy)
goto fail;
{
2026-02-26 14:32:50 +01:00
char* endptr = nullptr;
2026-01-08 10:32:31 +01:00
char* tok = strtok_s(copy, "\n", &endptr);
while (tok)
{
const size_t tok_len = strnlen(tok, pSize);
if (!process_uri(clipboard, tok, tok_len))
goto fail;
if (pSize < tok_len)
goto fail;
pSize -= WINPR_ASSERTING_INT_CAST(uint32_t, tok_len);
2026-02-26 14:32:50 +01:00
tok = strtok_s(nullptr, "\n", &endptr);
2026-01-08 10:32:31 +01:00
}
}
2026-01-08 10:32:31 +01:00
rc = TRUE;
fail:
free(copy);
return rc;
}
static BOOL process_gnome_copied_files(wClipboard* clipboard, const char* data, UINT32 pSize)
{
return process_files(clipboard, data, pSize, "copy\n");
}
static BOOL process_mate_copied_files(wClipboard* clipboard, const char* data, UINT32 pSize)
{
return process_files(clipboard, data, pSize, "copy\n");
}
2023-02-21 15:46:21 +01:00
static void* convert_gnome_copied_files_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize)
{
const UINT32 expected = ClipboardGetFormatId(clipboard, mime_gnome_copied_files);
if (formatId != expected)
2026-02-26 14:32:50 +01:00
return nullptr;
2023-02-21 15:46:21 +01:00
if (!process_gnome_copied_files(clipboard, (const char*)data, *pSize))
2026-02-26 14:32:50 +01:00
return nullptr;
2023-02-21 15:46:21 +01:00
return convert_any_uri_list_to_filedescriptors(clipboard, formatId, pSize);
}
static void* convert_mate_copied_files_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize)
{
const UINT32 expected = ClipboardGetFormatId(clipboard, mime_mate_copied_files);
if (formatId != expected)
2026-02-26 14:32:50 +01:00
return nullptr;
2023-02-21 15:46:21 +01:00
if (!process_mate_copied_files(clipboard, (const char*)data, *pSize))
2026-02-26 14:32:50 +01:00
return nullptr;
2023-02-21 15:46:21 +01:00
return convert_any_uri_list_to_filedescriptors(clipboard, formatId, pSize);
}
static size_t count_special_chars(const WCHAR* str)
{
size_t count = 0;
const WCHAR* start = str;
WINPR_ASSERT(str);
while (*start)
{
const WCHAR sharp = '#';
const WCHAR questionmark = '?';
const WCHAR star = '*';
const WCHAR exclamationmark = '!';
const WCHAR percent = '%';
if ((*start == sharp) || (*start == questionmark) || (*start == star) ||
(*start == exclamationmark) || (*start == percent))
{
count++;
}
start++;
}
return count;
}
2021-08-02 12:13:34 +02:00
static const char* stop_at_special_chars(const char* str)
{
const char* start = str;
WINPR_ASSERT(str);
while (*start)
{
if (*start == '#' || *start == '?' || *start == '*' || *start == '!' || *start == '%')
{
return start;
}
start++;
}
2026-02-26 14:32:50 +01:00
return nullptr;
}
/* The universal converter from filedescriptors to different file lists */
static void* convert_filedescriptors_to_file_list(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize,
const char* header, const char* lineprefix,
const char* lineending, BOOL skip_last_lineending)
{
union
{
char c[2];
WCHAR w;
} backslash;
backslash.c[0] = '\\';
backslash.c[1] = '\0';
2026-02-26 14:32:50 +01:00
const FILEDESCRIPTORW* descriptors = nullptr;
UINT32 nrDescriptors = 0;
size_t count = 0;
size_t alloc = 0;
size_t pos = 0;
size_t baseLength = 0;
2026-02-26 14:32:50 +01:00
char* dst = nullptr;
size_t header_len = strlen(header);
size_t lineprefix_len = strlen(lineprefix);
size_t lineending_len = strlen(lineending);
size_t decoration_len = 0;
if (!clipboard || !data || !pSize)
2026-02-26 14:32:50 +01:00
return nullptr;
if (*pSize < sizeof(UINT32))
2026-02-26 14:32:50 +01:00
return nullptr;
if (clipboard->delegate.basePath)
baseLength = strnlen(clipboard->delegate.basePath, MAX_PATH);
if (baseLength < 1)
2026-02-26 14:32:50 +01:00
return nullptr;
wStream sbuffer = WINPR_C_ARRAY_INIT;
wStream* s = Stream_StaticConstInit(&sbuffer, data, *pSize);
if (!Stream_CheckAndLogRequiredLength(TAG, s, 4))
2026-02-26 14:32:50 +01:00
return nullptr;
Stream_Read_UINT32(s, nrDescriptors);
2020-09-17 15:21:45 +02:00
count = (*pSize - 4) / sizeof(FILEDESCRIPTORW);
if ((count < 1) || (count != nrDescriptors))
2026-02-26 14:32:50 +01:00
return nullptr;
descriptors = Stream_ConstPointer(s);
if (formatId != ClipboardGetFormatId(clipboard, mime_FileGroupDescriptorW))
2026-02-26 14:32:50 +01:00
return nullptr;
/* Plus 1 for '/' between basepath and filename*/
decoration_len = lineprefix_len + lineending_len + baseLength + 1;
alloc = header_len;
/* Get total size of file/folder names under first level folder only */
for (size_t x = 0; x < count; x++)
{
const FILEDESCRIPTORW* dsc = &descriptors[x];
2026-02-26 14:32:50 +01:00
if (_wcschr(dsc->cFileName, backslash.w) == nullptr)
{
alloc += ARRAYSIZE(dsc->cFileName) *
8; /* Overallocate, just take the biggest value the result path can have */
/* # (1 char) -> %23 (3 chars) , the first char is replaced inplace */
alloc += count_special_chars(dsc->cFileName) * sizeof(WCHAR);
alloc += decoration_len;
}
}
/* Append a prefix file:// and postfix \n for each file */
/* We need to keep last \n since snprintf is null terminated!! */
alloc++;
dst = calloc(alloc, sizeof(char));
if (!dst)
2026-02-26 14:32:50 +01:00
return nullptr;
(void)_snprintf(&dst[0], alloc, "%s", header);
pos = header_len;
for (size_t x = 0; x < count; x++)
{
const FILEDESCRIPTORW* dsc = &descriptors[x];
2022-04-28 10:49:42 +02:00
BOOL fail = TRUE;
2026-02-26 14:32:50 +01:00
if (_wcschr(dsc->cFileName, backslash.w) != nullptr)
{
continue;
}
int rc = -1;
char curName[520] = WINPR_C_ARRAY_INIT;
2026-02-26 14:32:50 +01:00
const char* stop_at = nullptr;
const char* previous_at = nullptr;
if (ConvertWCharNToUtf8(dsc->cFileName, ARRAYSIZE(dsc->cFileName), curName,
ARRAYSIZE(curName)) < 0)
2022-04-28 10:49:42 +02:00
goto loop_fail;
rc = _snprintf(&dst[pos], alloc - pos, "%s%s/", lineprefix, clipboard->delegate.basePath);
if (rc < 0)
2022-04-28 10:49:42 +02:00
goto loop_fail;
pos += (size_t)rc;
previous_at = curName;
2026-02-26 14:32:50 +01:00
while ((stop_at = stop_at_special_chars(previous_at)) != nullptr)
{
2025-03-26 19:41:39 +01:00
const intptr_t diff = stop_at - previous_at;
if (diff < 0)
goto loop_fail;
char* tmp = strndup(previous_at, WINPR_ASSERTING_INT_CAST(size_t, diff));
if (!tmp)
2022-04-28 10:49:42 +02:00
goto loop_fail;
2025-03-26 19:41:39 +01:00
rc = _snprintf(&dst[pos], WINPR_ASSERTING_INT_CAST(size_t, diff + 1), "%s", tmp);
free(tmp);
if (rc < 0)
2022-04-28 10:49:42 +02:00
goto loop_fail;
pos += (size_t)rc;
rc = _snprintf(&dst[pos], 4, "%%%x", *stop_at);
if (rc < 0)
2022-04-28 10:49:42 +02:00
goto loop_fail;
pos += (size_t)rc;
previous_at = stop_at + 1;
}
rc = _snprintf(&dst[pos], alloc - pos, "%s%s", previous_at, lineending);
2022-04-28 10:49:42 +02:00
fail = FALSE;
loop_fail:
if ((rc < 0) || fail)
{
free(dst);
2026-02-26 14:32:50 +01:00
return nullptr;
}
pos += (size_t)rc;
}
if (skip_last_lineending)
{
const size_t endlen = strlen(lineending);
if (alloc > endlen)
{
const size_t len = strnlen(dst, alloc);
if (len < endlen)
{
free(dst);
2026-02-26 14:32:50 +01:00
return nullptr;
}
if (memcmp(&dst[len - endlen], lineending, endlen) == 0)
{
memset(&dst[len - endlen], 0, endlen);
alloc -= endlen;
}
}
}
alloc = strnlen(dst, alloc) + 1;
*pSize = (UINT32)alloc;
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
return dst;
}
/* Prepend header of kde dolphin format to file list
* See:
* GTK: https://docs.gtk.org/glib/struct.Uri.html
* uri syntax: https://www.rfc-editor.org/rfc/rfc3986#section-3
* uri-lists format: https://www.rfc-editor.org/rfc/rfc2483#section-5
*/
static void* convert_filedescriptors_to_uri_list(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize)
{
return convert_filedescriptors_to_file_list(clipboard, formatId, data, pSize, "", "file://",
"\r\n", FALSE);
}
/* Prepend header of common gnome format to file list*/
static void* convert_filedescriptors_to_gnome_copied_files(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize)
{
return convert_filedescriptors_to_file_list(clipboard, formatId, data, pSize, "copy\n",
"file://", "\n", TRUE);
}
static void* convert_filedescriptors_to_mate_copied_files(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize)
{
char* pDstData = convert_filedescriptors_to_file_list(clipboard, formatId, data, pSize,
"copy\n", "file://", "\n", TRUE);
if (!pDstData)
{
return pDstData;
}
/* Replace last \n with \0
see
mate-desktop/caja/libcaja-private/caja-clipboard.c:caja_clipboard_get_uri_list_from_selection_data
*/
pDstData[*pSize - 1] = '\0';
*pSize = *pSize - 1;
return pDstData;
}
2022-10-27 14:13:00 +02:00
static void array_free_synthetic_file(void* the_file)
{
struct synthetic_file* file = the_file;
free_synthetic_file(file);
}
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
static BOOL register_file_formats_and_synthesizers(wClipboard* clipboard)
{
2026-02-26 14:32:50 +01:00
wObject* obj = nullptr;
2023-02-21 15:46:21 +01:00
/*
1. Gnome Nautilus based file manager (Nautilus only with version >= 3.30 AND < 40):
TARGET: UTF8_STRING
format: x-special/nautilus-clipboard\copy\n\file://path\n\0
2. Kde Dolpin and Qt:
TARGET: text/uri-list
format: file:path\r\n\0
See:
GTK: https://docs.gtk.org/glib/struct.Uri.html
uri syntax: https://www.rfc-editor.org/rfc/rfc3986#section-3
2024-11-20 16:53:40 -05:00
uri-lists format: https://www.rfc-editor.org/rfc/rfc2483#section-5
2023-02-21 15:46:21 +01:00
3. Gnome and others (Unity/XFCE/Nautilus < 3.30/Nautilus >= 40):
TARGET: x-special/gnome-copied-files
format: copy\nfile://path\n\0
4. Mate Caja:
TARGET: x-special/mate-copied-files
format: copy\nfile://path\n
TODO: other file managers do not use previous targets and formats.
*/
const UINT32 local_gnome_file_format_id =
ClipboardRegisterFormat(clipboard, mime_gnome_copied_files);
const UINT32 local_mate_file_format_id =
ClipboardRegisterFormat(clipboard, mime_mate_copied_files);
const UINT32 file_group_format_id =
ClipboardRegisterFormat(clipboard, mime_FileGroupDescriptorW);
const UINT32 local_file_format_id = ClipboardRegisterFormat(clipboard, mime_uri_list);
2023-02-21 15:46:21 +01:00
if (!file_group_format_id || !local_file_format_id || !local_gnome_file_format_id ||
!local_mate_file_format_id)
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
goto error;
clipboard->localFiles = ArrayList_New(FALSE);
2017-11-14 13:57:00 +01:00
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
if (!clipboard->localFiles)
goto error;
obj = ArrayList_Object(clipboard->localFiles);
2022-10-27 14:13:00 +02:00
obj->fnObjectFree = array_free_synthetic_file;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
2019-11-06 15:24:51 +01:00
if (!ClipboardRegisterSynthesizer(clipboard, local_file_format_id, file_group_format_id,
2017-11-14 13:57:00 +01:00
convert_uri_list_to_filedescriptors))
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
goto error_free_local_files;
2019-11-06 15:24:51 +01:00
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_file_format_id,
convert_filedescriptors_to_uri_list))
goto error_free_local_files;
2023-02-21 15:46:21 +01:00
if (!ClipboardRegisterSynthesizer(clipboard, local_gnome_file_format_id, file_group_format_id,
convert_gnome_copied_files_to_filedescriptors))
goto error_free_local_files;
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_gnome_file_format_id,
convert_filedescriptors_to_gnome_copied_files))
goto error_free_local_files;
if (!ClipboardRegisterSynthesizer(clipboard, local_mate_file_format_id, file_group_format_id,
convert_mate_copied_files_to_filedescriptors))
goto error_free_local_files;
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_mate_file_format_id,
convert_filedescriptors_to_mate_copied_files))
goto error_free_local_files;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
return TRUE;
error_free_local_files:
ArrayList_Free(clipboard->localFiles);
2026-02-26 14:32:50 +01:00
clipboard->localFiles = nullptr;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
error:
return FALSE;
}
static int32_t file_get_size(const struct synthetic_file* file, UINT64* size)
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
{
UINT64 s = 0;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
if (!file || !size)
return E_INVALIDARG;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
s = file->nFileSizeHigh;
s <<= 32;
s |= file->nFileSizeLow;
*size = s;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
return NO_ERROR;
}
static UINT delegate_file_request_size(wClipboardDelegate* delegate,
const wClipboardFileSizeRequest* request)
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
{
UINT64 size = 0;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
if (!delegate || !delegate->clipboard || !request)
return ERROR_BAD_ARGUMENTS;
if (delegate->clipboard->sequenceNumber != delegate->clipboard->fileListSequenceNumber)
return ERROR_INVALID_STATE;
2025-02-10 13:00:48 +01:00
struct synthetic_file* file =
ArrayList_GetItem(delegate->clipboard->localFiles, request->listIndex);
2017-11-14 13:57:00 +01:00
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
if (!file)
return ERROR_INDEX_ABSENT;
2025-02-10 13:00:48 +01:00
const int32_t s = file_get_size(file, &size);
uint32_t error = 0;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
if (error)
2025-02-10 13:00:48 +01:00
error = delegate->ClipboardFileSizeFailure(delegate, request, (UINT)s);
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
else
error = delegate->ClipboardFileSizeSuccess(delegate, request, size);
if (error)
WLog_WARN(TAG, "failed to report file size result: 0x%08X", error);
return NO_ERROR;
}
UINT synthetic_file_read_close(struct synthetic_file* file, BOOL force)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
if (!file || INVALID_HANDLE_VALUE == file->fd)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
return NO_ERROR;
/* Always force close the file. Clipboard might open hundreds of files
* so avoid caching to prevent running out of available file descriptors */
UINT64 size = 0;
file_get_size(file, &size);
2022-12-05 08:58:38 +01:00
if ((file->offset < 0) || ((UINT64)file->offset >= size) || force)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
WLog_VRB(TAG, "close file %p", file->fd);
if (!CloseHandle(file->fd))
{
WLog_WARN(TAG, "failed to close fd %p: %" PRIu32, file->fd, GetLastError());
}
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
file->fd = INVALID_HANDLE_VALUE;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
}
return NO_ERROR;
}
static UINT file_get_range(struct synthetic_file* file, UINT64 offset, UINT32 size,
BYTE** actual_data, UINT32* actual_size)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
UINT error = NO_ERROR;
DWORD dwLow = 0;
DWORD dwHigh = 0;
2017-11-14 13:57:00 +01:00
WINPR_ASSERT(file);
WINPR_ASSERT(actual_data);
WINPR_ASSERT(actual_size);
if (INVALID_HANDLE_VALUE == file->fd)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
BY_HANDLE_FILE_INFORMATION FileInfo = WINPR_C_ARRAY_INIT;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
2026-02-26 14:32:50 +01:00
file->fd = CreateFileW(file->local_name, GENERIC_READ, 0, nullptr, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, nullptr);
if (INVALID_HANDLE_VALUE == file->fd)
{
char name[MAX_PATH] = WINPR_C_ARRAY_INIT;
ConvertWCharToUtf8(file->local_name, name, sizeof(name) - 1);
error = GetLastError();
WLog_ERR(TAG, "failed to open file %s: 0x%08" PRIx32, name, error);
return error;
}
2017-11-14 13:57:00 +01:00
if (!GetFileInformationByHandle(file->fd, &FileInfo))
{
char name[MAX_PATH] = WINPR_C_ARRAY_INIT;
ConvertWCharToUtf8(file->local_name, name, sizeof(name) - 1);
2024-09-16 04:58:36 +02:00
(void)CloseHandle(file->fd);
2024-04-17 09:22:31 +02:00
file->fd = INVALID_HANDLE_VALUE;
error = GetLastError();
WLog_ERR(TAG, "Get file [%s] information fail: 0x%08" PRIx32, name, error);
return error;
}
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
file->offset = 0;
file->nFileSizeHigh = FileInfo.nFileSizeHigh;
file->nFileSizeLow = FileInfo.nFileSizeLow;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
/*
{
UINT64 s = 0;
file_get_size(file, &s);
WLog_DBG(TAG, "open file %d -> %s", file->fd, file->local_name);
WLog_DBG(TAG, "file %d size: %" PRIu64 " bytes", file->fd, s);
} //*/
}
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
do
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
/*
* We should avoid seeking when possible as some filesystems (e.g.,
* an FTP server mapped via FUSE) may not support seeking. We keep
* an accurate account of the current file offset and do not call
* lseek() if the client requests file content sequentially.
*/
if (offset > INT64_MAX)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
WLog_ERR(TAG, "offset [%" PRIu64 "] > INT64_MAX", offset);
error = ERROR_SEEK;
break;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
}
2017-11-14 13:57:00 +01:00
if (file->offset != (INT64)offset)
{
WLog_DBG(TAG, "file %p force seeking to %" PRIu64 ", current %" PRId64, file->fd,
offset, file->offset);
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
dwHigh = offset >> 32;
dwLow = offset & 0xFFFFFFFF;
if (INVALID_SET_FILE_POINTER == SetFilePointer(file->fd,
WINPR_ASSERTING_INT_CAST(LONG, dwLow),
(PLONG)&dwHigh, FILE_BEGIN))
{
error = GetLastError();
break;
}
}
2017-11-14 13:57:00 +01:00
2024-04-11 12:27:01 +02:00
BYTE* buffer = malloc(size);
if (!buffer)
{
error = ERROR_NOT_ENOUGH_MEMORY;
break;
}
2026-02-26 14:32:50 +01:00
if (!ReadFile(file->fd, buffer, size, (LPDWORD)actual_size, nullptr))
{
2024-04-11 12:27:01 +02:00
free(buffer);
error = GetLastError();
break;
}
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
*actual_data = buffer;
file->offset += *actual_size;
WLog_VRB(TAG, "file %p actual read %" PRIu32 " bytes (offset %" PRId64 ")", file->fd,
*actual_size, file->offset);
} while (0);
2021-03-26 10:52:35 +01:00
synthetic_file_read_close(file, TRUE /* (error != NO_ERROR) && (size > 0) */);
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
return error;
}
static UINT delegate_file_request_range(wClipboardDelegate* delegate,
const wClipboardFileRangeRequest* request)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
UINT error = 0;
2026-02-26 14:32:50 +01:00
BYTE* data = nullptr;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
UINT32 size = 0;
UINT64 offset = 0;
2026-02-26 14:32:50 +01:00
struct synthetic_file* file = nullptr;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
if (!delegate || !delegate->clipboard || !request)
return ERROR_BAD_ARGUMENTS;
if (delegate->clipboard->sequenceNumber != delegate->clipboard->fileListSequenceNumber)
return ERROR_INVALID_STATE;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
file = ArrayList_GetItem(delegate->clipboard->localFiles, request->listIndex);
2017-11-14 13:57:00 +01:00
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
if (!file)
return ERROR_INDEX_ABSENT;
2019-11-06 15:24:51 +01:00
offset = (((UINT64)request->nPositionHigh) << 32) | ((UINT64)request->nPositionLow);
error = file_get_range(file, offset, request->cbRequested, &data, &size);
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
if (error)
error = delegate->ClipboardFileRangeFailure(delegate, request, error);
else
error = delegate->ClipboardFileRangeSuccess(delegate, request, data, size);
if (error)
WLog_WARN(TAG, "failed to report file range result: 0x%08X", error);
free(data);
return NO_ERROR;
}
static UINT dummy_file_size_success(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
WINPR_ATTR_UNUSED const wClipboardFileSizeRequest* request,
WINPR_ATTR_UNUSED UINT64 fileSize)
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
{
return ERROR_NOT_SUPPORTED;
}
static UINT dummy_file_size_failure(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
WINPR_ATTR_UNUSED const wClipboardFileSizeRequest* request,
WINPR_ATTR_UNUSED UINT errorCode)
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
{
return ERROR_NOT_SUPPORTED;
}
static UINT dummy_file_range_success(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
WINPR_ATTR_UNUSED const wClipboardFileRangeRequest* request,
WINPR_ATTR_UNUSED const BYTE* data,
WINPR_ATTR_UNUSED UINT32 size)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
return ERROR_NOT_SUPPORTED;
}
static UINT dummy_file_range_failure(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
WINPR_ATTR_UNUSED const wClipboardFileRangeRequest* request,
WINPR_ATTR_UNUSED UINT errorCode)
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
{
return ERROR_NOT_SUPPORTED;
}
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
static void setup_delegate(wClipboardDelegate* delegate)
{
WINPR_ASSERT(delegate);
delegate->ClientRequestFileSize = delegate_file_request_size;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
delegate->ClipboardFileSizeSuccess = dummy_file_size_success;
delegate->ClipboardFileSizeFailure = dummy_file_size_failure;
delegate->ClientRequestFileRange = delegate_file_request_range;
wClipboard/posix: implement file range retrieval This is another bunch of callbacks which provide the file contents to the clients. We jump through some extra hoops in order to have more pleasant user experience. Simple stuff goes first. The file offset (or position) is split into the low and high parts because this is the format in which the clients receive the request from the server. They can simply copy the values as is into the struct without repackaging them (which we do instead in the end to get a 64-bit off_t). Another thing is that we try to minimize the number of lseek() calls and to keep as few file descriptors open as possible. We cannot open all the files at once as there could be thousands of them and we'll run out of the allowed number of the fds. However, the server can (in theory) request the file ranges randomly so we need to be prepared for that. One way to do that would be to always open the file before reading and close it immediately afterwards. A dead simple solution with an acceptable performance, but... some file systems do not support seeking, such as FTP directories mounted over FUSE. However, they handle sequential reading just fine *and* the server requests the data sequentially most of the time so we can exploit this. Thus open the file only once, during the first range request and keep it open until the server reads all the data. In order to know how much data is left we keep an accurate account of all reads and maintain the file offset ourselves. This also allows us to avoid calling lseek() when the file offset will not be effectively changed. However, if the server requests some weird offset then we have no choice and will attempt seeking. Unfortunately, we cannot tell whether it is a genuine failure or the file system just does not support seeking, so we do not handle the error further. (One workaround would be to reopen the file and keep reading it until we're at the correct offset.) In this way we can support sequential-only file systems if the server requests the contents sequentially (and it does). Also note that we do an fstat() right after opening the file in order to have an accurate value of file size, for this exact file descriptor we will be using. We should have it filled it by now, but just in case... There is one more thing to explain. The cbRequested field specifies the maximum number of bytes the server can handle, not the required number. Usually this is some power-of-two number like 64 KB, based on the size of the files on the clipboard. This is why posix_file_read_perform() does not attempt to fill the whole buffer by repeatedly calling read() if it has read less data than requested. The server can handle underruns just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
delegate->ClipboardFileRangeSuccess = dummy_file_range_success;
delegate->ClipboardFileRangeFailure = dummy_file_range_failure;
delegate->IsFileNameComponentValid = ValidFileNameComponent;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
}
BOOL ClipboardInitSyntheticFileSubsystem(wClipboard* clipboard)
{
if (!clipboard)
return FALSE;
wClipboard/posix: basic file list handling Here you can see an outline of our approach to handling file lists put on the clipboard. Typical usage of wClipboard by the clients sums up to doing a ClipboardSetData() call followed by a ClipboardGetData() call with appropriate format ID passed to them. Thus for files we would expect the clients to first set the local format (like "text/uri-list") and then to get the remote format (the "FileGroupDescriptorW"). MS-RDPECLIP has a concept of locally-stored list of files on the clipboard. This is modeled by clipboard->localFiles ArrayList. We need to populate this list before we serialize it into CLIPRDR_FILELIST and send it to the server. The easiest way to achieve this is a bit hacky, but it works: we populate the file list from inside the synthesizer callback registered for text/uri-list -> FileGroupDescriptorW conversion. So the client would first set the data it received from local clipboard as "text/uri-list" format, then it gets a "FileGroupDescriptorW" format, during that conversion we will prepare to serve file content requests, and in the end we provide a FILEDESCRIPTOR array to the client as the conversion result. The client will then serialize the array into CLIPRDR_FILELIST and sent it to the server. (We cannot do serialization in WinPR as WinPR should not know about cliprdr and its data formats.) The subsystems are expected to store their private structures in the clipboard->localFiles array. POSIX subsystem uses struct posix_file which currently has bare minimum of fields: the local file name (for open() and the like) and the remote file name (the one to put into FILEDESCRIPTOR).
2017-04-09 02:29:50 +03:00
if (!register_file_formats_and_synthesizers(clipboard))
return FALSE;
wClipboard/posix: implement file size retrieval This is an example of wClipboardDelegate method implementation. POSIX subsystem uses synchronous methods, but the interface can be used for asynchronous request processing as well. The client should call a Client* callback to request some action and the wClipboard will process the request and report the result by calling an approriate Clipboard* callback. Usually there will be two callbacks: one for reporting success and one to report errors. All callbacks have at least two arguments: the wClipboardDelegate itself to pass the system context, and the wClipboard*Request structure with the arguments to pass the call context. The request context is also passed to the result callbacks by wClipboard so that the client can match up the result with its previous request. The fields of wClipboard*Request structures are heavily influenced by the MS-RDPECLIP spec and mirror the respective fields of CLIPRDR_FILECONTENTS_REQUEST. wClipboard should not depend on MS-RDPECLIP, that's the reason we don't use CLIPRDR_FILECONTENTS_REQUEST directly. However, I believe that we should not have void* fields in the request structs so that they can be easily copied around if needed. This is why have the weird 'streamId' field there which has nothing to do with wClipboard and will be used only by the clients when sending replies to the server. Return values of the callbacks are to be used for reporting errors with processing the request or reply per se, not for errors encountered while performing the action requested. Thus, for example, we return NO_ERROR from posix_file_request_size() even when we fail to report the result to the client, because we have successfully performed the request and do not care if the client could not handle our reply for some reason. Also note that setup_delegate() fills in dummy implementations of Clipboard* reply callbacks so that we do not crash in case the client does not fill them and do not have to perform paranoid NULL checks before calling every single callback.
2017-04-09 02:29:51 +03:00
setup_delegate(&clipboard->delegate);
return TRUE;
}