FreeRDP/winpr/libwinpr/clipboard/posix.c

961 lines
23 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.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#define _FILE_OFFSET_BITS 64
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 <stddef.h>
#include <stdlib.h>
#include <errno.h>
#include <dirent.h>
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
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.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 14:49:19 +03: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 "clipboard.h"
#include "posix.h"
#include "../log.h"
#define TAG WINPR_TAG("clipboard.posix")
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
struct posix_file
{
char* local_name;
WCHAR* remote_name;
BOOL is_directory;
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
int fd;
INT64 offset;
INT64 size;
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 struct posix_file* make_posix_file(const char* local_name, const WCHAR* remote_name)
{
struct posix_file* file = NULL;
struct stat statbuf;
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 = calloc(1, sizeof(*file));
2017-11-14 15:57:00 +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
if (!file)
return NULL;
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 = -1;
file->offset = 0;
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->local_name = _strdup(local_name);
file->remote_name = _wcsdup(remote_name);
if (!file->local_name || !file->remote_name)
goto error;
if (stat(local_name, &statbuf))
{
int err = errno;
WLog_ERR(TAG, "failed to stat %s: %s", local_name, strerror(err));
goto error;
}
file->is_directory = S_ISDIR(statbuf.st_mode);
file->size = statbuf.st_size;
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 file;
error:
free(file->local_name);
free(file->remote_name);
free(file);
return NULL;
}
static void free_posix_file(void* the_file)
{
struct posix_file* file = the_file;
if (!file)
return;
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->fd >= 0)
{
if (close(file->fd) < 0)
{
int err = errno;
WLog_WARN(TAG, "failed to close fd %d: %s", file->fd, strerror(err));
}
}
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);
}
static unsigned char hex_to_dec(char c, BOOL* valid)
{
if (('0' <= c) && (c <= '9'))
return (c - '0');
if (('a' <= c) && (c <= 'f'))
return (c - 'a') + 10;
if (('A' <= c) && (c <= 'F'))
return (c - 'A') + 10;
*valid = FALSE;
return 0;
}
static BOOL decode_percent_encoded_byte(const char* str, const char* end, char* value)
{
BOOL valid = TRUE;
2019-02-07 16:34:37 +03:00
if ((end < str) || ((size_t)(end - str) < strlen("%20")))
return FALSE;
*value = 0;
*value |= hex_to_dec(str[1], &valid);
*value <<= 4;
*value |= hex_to_dec(str[2], &valid);
return valid;
}
static char* decode_percent_encoded_string(const char* str, size_t len)
{
char* buffer = NULL;
char* next = NULL;
const char* cur = str;
const char* lim = str + len;
/* Percent decoding shrinks data length, so len bytes will be enough. */
buffer = calloc(len + 1, sizeof(char));
2017-11-14 15:57:00 +03:00
if (!buffer)
return NULL;
next = buffer;
while (cur < lim)
{
if (*cur != '%')
{
*next++ = *cur++;
}
else
{
if (!decode_percent_encoded_byte(cur, lim, next))
{
WLog_ERR(TAG, "invalid percent encoding");
goto error;
}
cur += strlen("%20");
next += 1;
}
}
return buffer;
error:
free(buffer);
return NULL;
}
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(const char* local_name)
{
WCHAR* remote_name = NULL;
/*
* 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.
*/
if (!ConvertToUnicode(CP_UTF8, 0, local_name, -1, &remote_name, 0))
{
WLog_ERR(TAG, "Unicode conversion failed for %s", local_name);
goto error;
}
/*
* 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.
*/
if (!ValidFileNameComponent(remote_name))
{
WLog_ERR(TAG, "invalid file name component: %s", local_name);
goto error;
}
return remote_name;
error:
free(remote_name);
return NULL;
}
static char* concat_local_name(const char* dir, const char* file)
{
size_t len_dir = 0;
size_t len_file = 0;
char* buffer = NULL;
len_dir = strlen(dir);
len_file = strlen(file);
buffer = calloc(len_dir + 1 + len_file + 1, sizeof(char));
2017-11-14 15:57:00 +03:00
if (!buffer)
return NULL;
memcpy(buffer, dir, len_dir * sizeof(char));
buffer[len_dir] = '/';
memcpy(buffer + len_dir + 1, file, len_file * sizeof(char));
return buffer;
}
static WCHAR* concat_remote_name(const WCHAR* dir, const WCHAR* file)
{
size_t len_dir = 0;
size_t len_file = 0;
WCHAR* buffer = NULL;
len_dir = _wcslen(dir);
len_file = _wcslen(file);
buffer = calloc(len_dir + 1 + len_file + 2, sizeof(WCHAR));
2017-11-14 15:57:00 +03:00
if (!buffer)
return NULL;
memcpy(buffer, dir, len_dir * sizeof(WCHAR));
buffer[len_dir] = L'\\';
memcpy(buffer + len_dir + 1, file, len_file * sizeof(WCHAR));
return buffer;
}
static BOOL add_file_to_list(const char* local_name, const WCHAR* remote_name, wArrayList* files);
static BOOL add_directory_entry_to_list(const char* local_dir_name, const WCHAR* remote_dir_name,
2017-11-14 15:57:00 +03:00
const struct dirent* entry, wArrayList* files)
{
BOOL result = FALSE;
char* local_name = NULL;
WCHAR* remote_name = NULL;
WCHAR* remote_base_name = NULL;
/* Skip special directory entries. */
if ((strcmp(entry->d_name, ".") == 0) || (strcmp(entry->d_name, "..") == 0))
return TRUE;
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
remote_base_name = convert_local_name_component_to_remote(entry->d_name);
2017-11-14 15:57:00 +03: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_local_name(local_dir_name, entry->d_name);
remote_name = concat_remote_name(remote_dir_name, remote_base_name);
if (local_name && remote_name)
result = add_file_to_list(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(const char* local_name, const WCHAR* remote_name,
2017-11-14 15:57:00 +03:00
DIR* dirp, wArrayList* files)
{
/*
* For some reason POSIX does not require readdir() to be thread-safe.
* However, readdir_r() has really insane interface and is pretty bad
* replacement for it. Fortunately, most C libraries guarantee thread-
* safety of readdir() when it is used for distinct directory streams.
*
* Thus we can use readdir() in multithreaded applications if we are
* sure that it will not corrupt some global data. It would be nice
* to have a compile-time check for this here, but some C libraries
* do not provide a #define because of reasons (I'm looking at you,
* musl). We should not be breaking people's builds because of that,
* so we do nothing and proceed with fingers crossed.
*/
for (;;)
{
struct dirent* entry = NULL;
errno = 0;
entry = readdir(dirp);
2017-11-14 15:57:00 +03:00
if (!entry)
{
int err = errno;
2017-11-14 15:57:00 +03:00
if (!err)
break;
WLog_ERR(TAG, "failed to read directory: %s", strerror(err));
return FALSE;
}
if (!add_directory_entry_to_list(local_name, remote_name, entry, files))
return FALSE;
}
return TRUE;
}
static BOOL add_directory_contents_to_list(const char* local_name, const WCHAR* remote_name,
2017-11-14 15:57:00 +03:00
wArrayList* files)
{
BOOL result = FALSE;
DIR* dirp = NULL;
WLog_VRB(TAG, "adding directory: %s", local_name);
dirp = opendir(local_name);
2017-11-14 15:57:00 +03:00
if (!dirp)
{
int err = errno;
WLog_ERR(TAG, "failed to open directory %s: %s", local_name, strerror(err));
goto out;
}
result = do_add_directory_contents_to_list(local_name, remote_name, dirp, files);
if (closedir(dirp))
{
int err = errno;
WLog_WARN(TAG, "failed to close directory: %s", strerror(err));
}
2017-11-14 15:57:00 +03:00
out:
return result;
}
static BOOL add_file_to_list(const char* local_name, const WCHAR* remote_name, wArrayList* files)
{
struct posix_file* file = NULL;
WLog_VRB(TAG, "adding file: %s", local_name);
file = make_posix_file(local_name, remote_name);
2017-11-14 15:57:00 +03:00
if (!file)
return FALSE;
if (ArrayList_Add(files, file) < 0)
{
free_posix_file(file);
return FALSE;
}
if (file->is_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(local_name, remote_name, files))
return FALSE;
}
return TRUE;
}
static const char* get_basename(const char* name)
{
const char* c = name;
const char* last_name = name;
while (*c++)
{
if (*c == '/')
last_name = c + 1;
}
return last_name;
}
static BOOL process_file_name(const char* local_name, wArrayList* files)
{
BOOL result = FALSE;
const char* base_name = NULL;
WCHAR* remote_name = NULL;
/*
* 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);
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
remote_name = convert_local_name_component_to_remote(base_name);
2017-11-14 15:57:00 +03: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(local_name, remote_name, files);
free(remote_name);
return result;
}
static BOOL process_uri(const char* uri, size_t uri_len, wArrayList* files)
{
const char* prefix = "file://";
BOOL result = FALSE;
char* name = NULL;
const size_t prefixLen = strnlen(prefix, sizeof (prefix));
WLog_VRB(TAG, "processing URI: %.*s", uri_len, uri);
if ((uri_len < prefixLen) || strncmp(uri, prefix, prefixLen))
{
WLog_ERR(TAG, "non-'file://' URI schemes are not supported");
goto out;
}
name = decode_percent_encoded_string(uri + prefixLen, uri_len - prefixLen);
2017-11-14 15:57:00 +03:00
if (!name)
goto out;
result = process_file_name(name, files);
out:
free(name);
return result;
}
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_uri_list(const char* data, size_t length, wArrayList* files)
{
const char* cur = data;
const char* lim = data + length;
const char* start = NULL;
const char* stop = NULL;
WLog_VRB(TAG, "processing URI list:\n%.*s", length, data);
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
ArrayList_Clear(files);
/*
* 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 == '#');
start = cur;
for (stop = cur; stop < lim; stop++)
{
if (*stop == '\r')
{
if ((stop + 1 < lim) && (*(stop + 1) == '\n'))
cur = stop + 2;
else
cur = stop + 1;
2017-11-14 15:57:00 +03:00
break;
}
2017-11-14 15:57:00 +03:00
if (*stop == '\n')
{
cur = stop + 1;
break;
}
}
2017-11-14 15:57:00 +03:00
if (stop == lim)
cur = lim;
if (comment)
continue;
if (!process_uri(start, stop - start, files))
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 posix_file* file,
2017-11-14 15:57:00 +03:00
FILEDESCRIPTOR* descriptor)
{
size_t remote_len = 0;
descriptor->dwFlags = FD_ATTRIBUTES | FD_FILESIZE | FD_SHOWPROGRESSUI;
if (file->is_directory)
{
descriptor->dwFileAttributes = FILE_ATTRIBUTE_DIRECTORY;
descriptor->nFileSizeLow = 0;
descriptor->nFileSizeHigh = 0;
}
else
{
descriptor->dwFileAttributes = FILE_ATTRIBUTE_NORMAL;
descriptor->nFileSizeLow = (file->size >> 0) & 0xFFFFFFFF;
descriptor->nFileSizeHigh = (file->size >> 32) & 0xFFFFFFFF;
}
remote_len = _wcslen(file->remote_name);
2017-11-14 15:57:00 +03:00
if (remote_len + 1 > ARRAYSIZE(descriptor->cFileName))
{
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;
}
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 FILEDESCRIPTOR* convert_local_file_list_to_filedescriptors(wArrayList* files)
{
int i;
int count = 0;
FILEDESCRIPTOR* descriptors = NULL;
count = ArrayList_Count(files);
descriptors = calloc(count, sizeof(descriptors[0]));
2017-11-14 15:57:00 +03:00
if (!descriptors)
goto error;
for (i = 0; i < count; i++)
{
const struct posix_file* file = ArrayList_GetItem(files, i);
if (!convert_local_file_to_filedescriptor(file, &descriptors[i]))
goto error;
}
return descriptors;
error:
free(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
return NULL;
}
static void* convert_uri_list_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
2017-11-14 15:57:00 +03: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
{
FILEDESCRIPTOR* descriptors = NULL;
if (!clipboard || !data || !pSize)
return NULL;
if (formatId != ClipboardGetFormatId(clipboard, "text/uri-list"))
return NULL;
if (!process_uri_list((const char*) data, *pSize, clipboard->localFiles))
return NULL;
descriptors = convert_local_file_list_to_filedescriptors(clipboard->localFiles);
2017-11-14 15:57:00 +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
if (!descriptors)
return NULL;
*pSize = ArrayList_Count(clipboard->localFiles) * sizeof(FILEDESCRIPTOR);
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
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 descriptors;
}
static void* convert_filedescriptors_to_uri_list(wClipboard* clipboard, UINT32 formatId,
const void* data, UINT32* pSize)
{
const FILEDESCRIPTOR* descriptors;
UINT32 nrDescriptors = 0;
size_t count, x, alloc, pos, baseLength = 0;
const char* src = (const char*) data;
char* dst;
if (!clipboard || !data || !pSize)
return NULL;
if (*pSize < sizeof(UINT32))
return NULL;
if (clipboard->delegate.basePath)
baseLength = strnlen(clipboard->delegate.basePath, MAX_PATH);
if (baseLength < 1)
return NULL;
if (clipboard->delegate.ClientRequestFileSize)
nrDescriptors = (UINT32)(src[3] << 24) | (UINT32)(src[2] << 16) | (UINT32)(src[1] << 8) |
(src[0] & 0xFF);
count = (*pSize - 4) / sizeof(FILEDESCRIPTOR);
if ((count < 1) || (count != nrDescriptors))
return NULL;
descriptors = (const FILEDESCRIPTOR*)&src[4];
if (formatId != ClipboardGetFormatId(clipboard, "FileGroupDescriptorW"))
return NULL;
alloc = 0;
/* Get total size of file names */
for (x = 0; x < count; x++)
alloc += _wcsnlen(descriptors[x].cFileName, ARRAYSIZE(descriptors[x].cFileName));
/* Append a prefix file:// and postfix \r\n for each file */
alloc += (sizeof("/\r\n") + baseLength) * count;
dst = calloc(alloc, sizeof(char));
if (!dst)
return NULL;
pos = 0;
for (x = 0; x < count; x++)
{
int rc;
const FILEDESCRIPTOR* cur = &descriptors[x];
size_t curLen = _wcsnlen(cur->cFileName, ARRAYSIZE(cur->cFileName));
char* curName = NULL;
rc = ConvertFromUnicode(CP_UTF8, 0, cur->cFileName, (int)curLen, &curName, 0, NULL, NULL);
if (rc != (int)curLen)
{
free(curName);
free(dst);
return NULL;
}
rc = _snprintf(&dst[pos], alloc - pos, "%s/%s\r\n", clipboard->delegate.basePath, curName);
free(curName);
if (rc < 0)
{
free(dst);
return NULL;
}
pos += (size_t)rc;
}
*pSize = (UINT32)alloc;
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
return dst;
}
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)
{
UINT32 file_group_format_id;
UINT32 local_file_format_id;
file_group_format_id = ClipboardRegisterFormat(clipboard, "FileGroupDescriptorW");
local_file_format_id = ClipboardRegisterFormat(clipboard, "text/uri-list");
2017-11-14 15:57:00 +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
if (!file_group_format_id || !local_file_format_id)
goto error;
clipboard->localFiles = ArrayList_New(FALSE);
2017-11-14 15:57:00 +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
if (!clipboard->localFiles)
goto error;
ArrayList_Object(clipboard->localFiles)->fnObjectFree = free_posix_file;
if (!ClipboardRegisterSynthesizer(clipboard,
2017-11-14 15:57:00 +03:00
local_file_format_id, file_group_format_id,
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;
if (!ClipboardRegisterSynthesizer(clipboard,
file_group_format_id, local_file_format_id,
convert_filedescriptors_to_uri_list))
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);
clipboard->localFiles = NULL;
error:
return FALSE;
}
static UINT posix_file_get_size(const struct posix_file* file, INT64* 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
{
struct stat statbuf;
if (stat(file->local_name, &statbuf) < 0)
{
int err = errno;
WLog_ERR(TAG, "failed to stat %s: %s", file->local_name, strerror(err));
return ERROR_FILE_INVALID;
}
*size = statbuf.st_size;
return NO_ERROR;
}
static UINT posix_file_request_size(wClipboardDelegate* delegate,
2017-11-14 15:57:00 +03:00
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
{
UINT error = NO_ERROR;
INT64 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
struct posix_file* file = NULL;
if (!delegate || !delegate->clipboard || !request)
return ERROR_BAD_ARGUMENTS;
if (delegate->clipboard->sequenceNumber != delegate->clipboard->fileListSequenceNumber)
return ERROR_INVALID_STATE;
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
file = ArrayList_GetItem(delegate->clipboard->localFiles, request->listIndex);
2017-11-14 15:57:00 +03: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;
error = posix_file_get_size(file, &size);
if (error)
error = delegate->ClipboardFileSizeFailure(delegate, request, error);
else
error = delegate->ClipboardFileSizeSuccess(delegate, request, size);
if (error)
WLog_WARN(TAG, "failed to report file size result: 0x%08X", error);
return NO_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
static UINT posix_file_read_open(struct posix_file* file)
{
struct stat statbuf;
if (file->fd >= 0)
return NO_ERROR;
file->fd = open(file->local_name, O_RDONLY);
2017-11-14 15:57:00 +03: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->fd < 0)
{
int err = errno;
WLog_ERR(TAG, "failed to open file %s: %s", file->local_name, strerror(err));
return ERROR_FILE_NOT_FOUND;
}
if (fstat(file->fd, &statbuf) < 0)
{
int err = errno;
WLog_ERR(TAG, "failed to stat file: %s", strerror(err));
return ERROR_FILE_INVALID;
}
file->offset = 0;
file->size = statbuf.st_size;
WLog_VRB(TAG, "open file %d -> %s", file->fd, file->local_name);
WLog_VRB(TAG, "file %d size: %"PRIu64" bytes", file->fd, file->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 NO_ERROR;
}
static UINT posix_file_read_seek(struct posix_file* file, UINT64 offset)
{
/*
* 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.
*/
2019-02-07 16:34:37 +03:00
if (offset > INT64_MAX)
return ERROR_SEEK;
if (file->offset == (INT64)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
return NO_ERROR;
WLog_VRB(TAG, "file %d force seeking to %"PRIu64", current %"PRIu64, file->fd,
2017-11-14 15:57:00 +03:00
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
2019-02-07 16:34:37 +03:00
if (lseek(file->fd, (off_t)offset, SEEK_SET) < 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
{
int err = errno;
WLog_ERR(TAG, "failed to seek file: %s", strerror(err));
return ERROR_SEEK;
}
return NO_ERROR;
}
static UINT posix_file_read_perform(struct posix_file* file, UINT32 size,
2017-11-14 15:57:00 +03:00
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
{
BYTE* buffer = NULL;
ssize_t amount = 0;
WLog_VRB(TAG, "file %d request read %"PRIu32" bytes", file->fd, 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
buffer = malloc(size);
2017-11-14 15:57:00 +03: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 (!buffer)
{
WLog_ERR(TAG, "failed to allocate %"PRIu32" buffer bytes", size);
return ERROR_NOT_ENOUGH_MEMORY;
}
amount = read(file->fd, buffer, size);
2017-11-14 15:57:00 +03: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 (amount < 0)
{
int err = errno;
WLog_ERR(TAG, "failed to read file: %s", strerror(err));
goto error;
}
*actual_data = buffer;
*actual_size = amount;
file->offset += amount;
WLog_VRB(TAG, "file %d actual read %"PRIu32" bytes (offset %"PRIu64")", file->fd,
2017-11-14 15:57:00 +03:00
amount, 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
return NO_ERROR;
error:
free(buffer);
return ERROR_READ_FAULT;
}
static UINT posix_file_read_close(struct posix_file* file)
{
if (file->fd < 0)
return NO_ERROR;
if (file->offset == file->size)
{
WLog_VRB(TAG, "close file %d", 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
if (close(file->fd) < 0)
{
int err = errno;
WLog_WARN(TAG, "failed to close fd %d: %s", file->fd, strerror(err));
}
2017-11-14 15:57:00 +03: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
file->fd = -1;
}
return NO_ERROR;
}
static UINT posix_file_get_range(struct posix_file* file, UINT64 offset, UINT32 size,
2017-11-14 15:57:00 +03:00
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;
error = posix_file_read_open(file);
2017-11-14 15:57:00 +03: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 (error)
goto out;
error = posix_file_read_seek(file, offset);
2017-11-14 15:57:00 +03: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 (error)
goto out;
error = posix_file_read_perform(file, size, actual_data, actual_size);
2017-11-14 15:57:00 +03: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 (error)
goto out;
error = posix_file_read_close(file);
2017-11-14 15:57:00 +03: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 (error)
goto out;
2017-11-14 15:57:00 +03: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
out:
return error;
}
static UINT posix_file_request_range(wClipboardDelegate* delegate,
2017-11-14 15:57:00 +03:00
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;
BYTE* data = NULL;
UINT32 size = 0;
UINT64 offset = 0;
struct posix_file* file = NULL;
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 15:57:00 +03: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;
offset = (((UINT64) request->nPositionHigh) << 32) | ((UINT64) request->nPositionLow);
error = posix_file_get_range(file, offset, request->cbRequested, &data, &size);
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;
}
2017-11-14 15:57:00 +03:00
static UINT dummy_file_size_success(wClipboardDelegate* delegate,
const wClipboardFileSizeRequest* request, 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;
}
2017-11-14 15:57:00 +03:00
static UINT dummy_file_size_failure(wClipboardDelegate* delegate,
const wClipboardFileSizeRequest* request, 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;
}
2017-11-14 15:57:00 +03:00
static UINT dummy_file_range_success(wClipboardDelegate* delegate,
const wClipboardFileRangeRequest* request, const BYTE* data, 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;
}
2017-11-14 15:57:00 +03:00
static UINT dummy_file_range_failure(wClipboardDelegate* delegate,
const wClipboardFileRangeRequest* request, 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)
{
delegate->ClientRequestFileSize = posix_file_request_size;
delegate->ClipboardFileSizeSuccess = dummy_file_size_success;
delegate->ClipboardFileSizeFailure = dummy_file_size_failure;
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->ClientRequestFileRange = posix_file_request_range;
delegate->ClipboardFileRangeSuccess = dummy_file_range_success;
delegate->ClipboardFileRangeFailure = dummy_file_range_failure;
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 ClipboardInitPosixFileSubsystem(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;
}