2017-04-09 02:29:50 +03:00
|
|
|
/**
|
|
|
|
|
* WinPR: Windows Portable Runtime
|
|
|
|
|
* Clipboard Functions: POSIX file handling
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2017 Alexei Lozovsky <a.lozovsky@gmail.com>
|
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*/
|
|
|
|
|
|
2022-02-16 10:08:00 +01:00
|
|
|
#include <winpr/config.h>
|
2023-10-11 17:03:39 +02:00
|
|
|
#include <winpr/platform.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2023-10-11 17:03:39 +02:00
|
|
|
WINPR_PRAGMA_DIAG_PUSH
|
|
|
|
|
WINPR_PRAGMA_DIAG_IGNORED_RESERVED_ID_MACRO
|
2024-09-12 12:01:49 +02:00
|
|
|
WINPR_PRAGMA_DIAG_IGNORED_UNUSED_MACRO
|
2021-09-08 15:37:45 +02:00
|
|
|
|
2024-09-03 10:30:30 +02:00
|
|
|
#define _FILE_OFFSET_BITS 64 // NOLINT(bugprone-reserved-identifier,cert-dcl37-c,cert-dcl51-cpp)
|
2021-09-08 15:37:45 +02:00
|
|
|
|
2023-10-11 17:03:39 +02:00
|
|
|
WINPR_PRAGMA_DIAG_POP
|
2021-09-08 15:37:45 +02:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <errno.h>
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
#include <winpr/wtypes.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2018-08-24 13:49:19 +02:00
|
|
|
#include <winpr/crt.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <winpr/clipboard.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <winpr/collections.h>
|
2017-04-09 02:29:52 +03:00
|
|
|
#include <winpr/file.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <winpr/shell.h>
|
|
|
|
|
#include <winpr/string.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <winpr/wlog.h>
|
2023-07-25 15:45:43 +02:00
|
|
|
#include <winpr/path.h>
|
2021-01-08 21:53:28 +08:00
|
|
|
#include <winpr/print.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
|
|
|
|
|
#include "clipboard.h"
|
2022-09-09 09:25:13 +08:00
|
|
|
#include "synthetic_file.h"
|
2017-04-09 02:29:50 +03:00
|
|
|
|
|
|
|
|
#include "../log.h"
|
2022-09-09 09:25:13 +08:00
|
|
|
#define TAG WINPR_TAG("clipboard.synthetic.file")
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2023-02-21 15:13:07 +01:00
|
|
|
static const char* mime_uri_list = "text/uri-list";
|
|
|
|
|
static const char* mime_FileGroupDescriptorW = "FileGroupDescriptorW";
|
2023-02-21 15:46:21 +01:00
|
|
|
static const char* mime_gnome_copied_files = "x-special/gnome-copied-files";
|
|
|
|
|
static const char* mime_mate_copied_files = "x-special/mate-copied-files";
|
2022-09-13 12:08:46 +02:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
struct synthetic_file
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
WCHAR* local_name;
|
2017-04-09 02:29:50 +03:00
|
|
|
WCHAR* remote_name;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
HANDLE fd;
|
2017-08-11 10:07:46 +02:00
|
|
|
INT64 offset;
|
2022-09-09 09:25:13 +08:00
|
|
|
|
|
|
|
|
DWORD dwFileAttributes;
|
|
|
|
|
FILETIME ftCreationTime;
|
|
|
|
|
FILETIME ftLastAccessTime;
|
|
|
|
|
FILETIME ftLastWriteTime;
|
|
|
|
|
DWORD nFileSizeHigh;
|
|
|
|
|
DWORD nFileSizeLow;
|
2017-04-09 02:29:50 +03:00
|
|
|
};
|
|
|
|
|
|
2022-10-27 14:13:00 +02:00
|
|
|
void free_synthetic_file(struct synthetic_file* file);
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static struct synthetic_file* make_synthetic_file(const WCHAR* local_name, const WCHAR* remote_name)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2026-02-26 14:32:50 +01:00
|
|
|
struct synthetic_file* file = nullptr;
|
2026-02-24 20:18:25 +01:00
|
|
|
WIN32_FIND_DATAW fd = WINPR_C_ARRAY_INIT;
|
2026-02-26 14:32:50 +01:00
|
|
|
HANDLE hFind = nullptr;
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(local_name);
|
|
|
|
|
WINPR_ASSERT(remote_name);
|
|
|
|
|
|
|
|
|
|
hFind = FindFirstFileW(local_name, &fd);
|
2022-09-09 09:25:13 +08:00
|
|
|
if (INVALID_HANDLE_VALUE == hFind)
|
|
|
|
|
{
|
2022-09-29 14:55:27 +02:00
|
|
|
WLog_ERR(TAG, "FindFirstFile failed (%" PRIu32 ")", GetLastError());
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2022-09-09 09:25:13 +08:00
|
|
|
}
|
|
|
|
|
FindClose(hFind);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
file = calloc(1, sizeof(*file));
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!file)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
file->fd = INVALID_HANDLE_VALUE;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
file->offset = 0;
|
2022-09-09 09:25:13 +08:00
|
|
|
file->local_name = _wcsdup(local_name);
|
2022-09-26 13:31:06 +02:00
|
|
|
if (!file->local_name)
|
|
|
|
|
goto fail;
|
2022-09-09 09:25:13 +08:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
file->remote_name = _wcsdup(remote_name);
|
|
|
|
|
if (!file->remote_name)
|
|
|
|
|
goto fail;
|
2022-09-09 09:25:13 +08:00
|
|
|
|
2026-01-08 10:32:31 +01:00
|
|
|
{
|
|
|
|
|
const size_t len = _wcslen(file->remote_name);
|
2026-03-02 18:46:22 +01:00
|
|
|
if (S_OK != PathCchConvertStyleW(file->remote_name, len, PATH_STYLE_WINDOWS))
|
|
|
|
|
goto fail;
|
2026-01-08 10:32:31 +01:00
|
|
|
}
|
2022-10-27 15:58:03 +02:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
file->dwFileAttributes = fd.dwFileAttributes;
|
2022-10-27 13:56:09 +02:00
|
|
|
file->ftCreationTime = fd.ftCreationTime;
|
|
|
|
|
file->ftLastWriteTime = fd.ftLastWriteTime;
|
|
|
|
|
file->ftLastAccessTime = fd.ftLastAccessTime;
|
2022-09-26 13:31:06 +02:00
|
|
|
file->nFileSizeHigh = fd.nFileSizeHigh;
|
|
|
|
|
file->nFileSizeLow = fd.nFileSizeLow;
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
return file;
|
|
|
|
|
fail:
|
2022-10-27 14:13:00 +02:00
|
|
|
free_synthetic_file(file);
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2017-04-09 02:29:50 +03:00
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static UINT synthetic_file_read_close(struct synthetic_file* file, BOOL force);
|
|
|
|
|
|
2022-10-27 14:13:00 +02:00
|
|
|
void free_synthetic_file(struct synthetic_file* file)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
|
|
|
|
if (!file)
|
|
|
|
|
return;
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
synthetic_file_read_close(file, TRUE);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
free(file->local_name);
|
|
|
|
|
free(file->remote_name);
|
|
|
|
|
free(file);
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2022-09-09 09:25:13 +08:00
|
|
|
static WCHAR* convert_local_name_component_to_remote(wClipboard* clipboard, const WCHAR* local_name)
|
2017-04-09 02:29:52 +03:00
|
|
|
{
|
2022-07-06 12:00:16 +02:00
|
|
|
wClipboardDelegate* delegate = ClipboardGetDelegate(clipboard);
|
2026-02-26 14:32:50 +01:00
|
|
|
WCHAR* remote_name = nullptr;
|
2017-04-09 02:29:52 +03:00
|
|
|
|
2022-07-06 12:00:16 +02:00
|
|
|
WINPR_ASSERT(delegate);
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
remote_name = _wcsdup(local_name);
|
2017-04-09 02:29:52 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Some file names are not valid on Windows. Check for these now
|
|
|
|
|
* so that we won't get ourselves into a trouble later as such names
|
|
|
|
|
* are known to crash some Windows shells when pasted via clipboard.
|
2022-07-06 12:00:16 +02:00
|
|
|
*
|
|
|
|
|
* The IsFileNameComponentValid callback can be overridden by the API
|
|
|
|
|
* user, if it is known, that the connected peer is not on the
|
|
|
|
|
* Windows platform.
|
2017-04-09 02:29:52 +03:00
|
|
|
*/
|
2022-07-06 12:00:16 +02:00
|
|
|
if (!delegate->IsFileNameComponentValid(remote_name))
|
2017-04-09 02:29:52 +03:00
|
|
|
{
|
2026-02-24 20:18:25 +01:00
|
|
|
char name[MAX_PATH] = WINPR_C_ARRAY_INIT;
|
2026-01-16 11:42:46 +01:00
|
|
|
ConvertWCharToUtf8(local_name, name, sizeof(name) - 1);
|
|
|
|
|
WLog_ERR(TAG, "invalid file name component: %s", name);
|
2017-04-09 02:29:52 +03:00
|
|
|
goto error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return remote_name;
|
|
|
|
|
error:
|
|
|
|
|
free(remote_name);
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2017-04-09 02:29:52 +03:00
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static WCHAR* concat_file_name(const WCHAR* dir, const WCHAR* file)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
size_t len_dir = 0;
|
|
|
|
|
size_t len_file = 0;
|
2022-09-26 13:31:06 +02:00
|
|
|
const WCHAR slash = '/';
|
2026-02-26 14:32:50 +01:00
|
|
|
WCHAR* buffer = nullptr;
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(dir);
|
|
|
|
|
WINPR_ASSERT(file);
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
len_dir = _wcslen(dir);
|
|
|
|
|
len_file = _wcslen(file);
|
2019-04-03 10:17:51 +02:00
|
|
|
buffer = calloc(len_dir + 1 + len_file + 2, sizeof(WCHAR));
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!buffer)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
memcpy(buffer, dir, len_dir * sizeof(WCHAR));
|
2022-09-26 13:31:06 +02:00
|
|
|
buffer[len_dir] = slash;
|
2017-04-09 02:29:51 +03:00
|
|
|
memcpy(buffer + len_dir + 1, file, len_file * sizeof(WCHAR));
|
|
|
|
|
return buffer;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL add_file_to_list(wClipboard* clipboard, const WCHAR* local_name,
|
2022-07-06 12:00:16 +02:00
|
|
|
const WCHAR* remote_name, wArrayList* files);
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL add_directory_entry_to_list(wClipboard* clipboard, const WCHAR* local_dir_name,
|
|
|
|
|
const WCHAR* remote_dir_name,
|
|
|
|
|
const LPWIN32_FIND_DATAW pFileData, wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
BOOL result = FALSE;
|
2026-02-26 14:32:50 +01:00
|
|
|
WCHAR* local_name = nullptr;
|
|
|
|
|
WCHAR* remote_name = nullptr;
|
|
|
|
|
WCHAR* remote_base_name = nullptr;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2026-02-24 20:18:25 +01:00
|
|
|
WCHAR dotbuffer[6] = WINPR_C_ARRAY_INIT;
|
|
|
|
|
WCHAR dotdotbuffer[6] = WINPR_C_ARRAY_INIT;
|
2023-12-12 09:18:30 +01:00
|
|
|
const WCHAR* dot = InitializeConstWCharFromUtf8(".", dotbuffer, ARRAYSIZE(dotbuffer));
|
|
|
|
|
const WCHAR* dotdot = InitializeConstWCharFromUtf8("..", dotdotbuffer, ARRAYSIZE(dotdotbuffer));
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
WINPR_ASSERT(local_dir_name);
|
|
|
|
|
WINPR_ASSERT(remote_dir_name);
|
|
|
|
|
WINPR_ASSERT(pFileData);
|
|
|
|
|
WINPR_ASSERT(files);
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
/* Skip special directory entries. */
|
2022-09-09 09:25:13 +08:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
if ((_wcscmp(pFileData->cFileName, dot) == 0) || (_wcscmp(pFileData->cFileName, dotdot) == 0))
|
2017-04-09 02:29:51 +03:00
|
|
|
return TRUE;
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
remote_base_name = convert_local_name_component_to_remote(clipboard, pFileData->cFileName);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:52 +03:00
|
|
|
if (!remote_base_name)
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
local_name = concat_file_name(local_dir_name, pFileData->cFileName);
|
|
|
|
|
remote_name = concat_file_name(remote_dir_name, remote_base_name);
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
if (local_name && remote_name)
|
2022-07-06 12:00:16 +02:00
|
|
|
result = add_file_to_list(clipboard, local_name, remote_name, files);
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
free(remote_base_name);
|
|
|
|
|
free(remote_name);
|
|
|
|
|
free(local_name);
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL do_add_directory_contents_to_list(wClipboard* clipboard, const WCHAR* local_name,
|
2023-07-23 10:30:09 +02:00
|
|
|
const WCHAR* remote_name, WCHAR* namebuf,
|
2022-07-06 12:00:16 +02:00
|
|
|
wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
WINPR_ASSERT(local_name);
|
|
|
|
|
WINPR_ASSERT(remote_name);
|
|
|
|
|
WINPR_ASSERT(files);
|
2023-07-23 10:30:09 +02:00
|
|
|
WINPR_ASSERT(namebuf);
|
2022-09-26 13:31:06 +02:00
|
|
|
|
2026-02-24 20:18:25 +01:00
|
|
|
WIN32_FIND_DATAW FindData = WINPR_C_ARRAY_INIT;
|
2023-07-23 10:30:09 +02:00
|
|
|
HANDLE hFind = FindFirstFileW(namebuf, &FindData);
|
2022-09-09 09:25:13 +08:00
|
|
|
if (INVALID_HANDLE_VALUE == hFind)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2023-07-23 10:30:09 +02:00
|
|
|
WLog_ERR(TAG, "FindFirstFile failed (%" PRIu32 ")", GetLastError());
|
2022-09-09 09:25:13 +08:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
while (TRUE)
|
|
|
|
|
{
|
2023-07-23 10:30:09 +02:00
|
|
|
if (!add_directory_entry_to_list(clipboard, local_name, remote_name, &FindData, files))
|
|
|
|
|
{
|
|
|
|
|
FindClose(hFind);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BOOL bRet = FindNextFileW(hFind, &FindData);
|
2022-09-09 09:25:13 +08:00
|
|
|
if (!bRet)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2023-07-23 10:30:09 +02:00
|
|
|
FindClose(hFind);
|
2022-09-09 09:25:13 +08:00
|
|
|
if (ERROR_NO_MORE_FILES == GetLastError())
|
|
|
|
|
return TRUE;
|
2022-10-27 13:18:08 +02:00
|
|
|
WLog_WARN(TAG, "FindNextFile failed (%" PRIu32 ")", GetLastError());
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL add_directory_contents_to_list(wClipboard* clipboard, const WCHAR* local_name,
|
2022-07-06 12:00:16 +02:00
|
|
|
const WCHAR* remote_name, wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
BOOL result = FALSE;
|
2024-03-18 10:05:30 +01:00
|
|
|
union
|
|
|
|
|
{
|
|
|
|
|
const char* c;
|
|
|
|
|
const WCHAR* w;
|
|
|
|
|
} wildcard;
|
2026-01-08 11:21:20 +01:00
|
|
|
const char buffer[6] = { '/', '\0', '*', '\0', '\0', '\0' };
|
2024-03-18 10:05:30 +01:00
|
|
|
wildcard.c = buffer;
|
2024-03-18 19:57:02 +01:00
|
|
|
const size_t wildcardLen = ARRAYSIZE(buffer) / sizeof(WCHAR);
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
WINPR_ASSERT(local_name);
|
|
|
|
|
WINPR_ASSERT(remote_name);
|
|
|
|
|
WINPR_ASSERT(files);
|
|
|
|
|
|
|
|
|
|
size_t len = _wcslen(local_name);
|
2023-12-12 09:18:30 +01:00
|
|
|
WCHAR* namebuf = calloc(len + wildcardLen, sizeof(WCHAR));
|
2022-09-26 13:31:06 +02:00
|
|
|
if (!namebuf)
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2023-07-25 15:45:43 +02:00
|
|
|
_wcsncat(namebuf, local_name, len);
|
2024-03-18 10:05:30 +01:00
|
|
|
_wcsncat(namebuf, wildcard.w, wildcardLen);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2023-07-23 10:30:09 +02:00
|
|
|
result = do_add_directory_contents_to_list(clipboard, local_name, remote_name, namebuf, files);
|
2022-09-26 13:31:06 +02:00
|
|
|
|
2023-07-23 10:30:09 +02:00
|
|
|
free(namebuf);
|
2017-04-09 02:29:51 +03:00
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL add_file_to_list(wClipboard* clipboard, const WCHAR* local_name,
|
2022-07-06 12:00:16 +02:00
|
|
|
const WCHAR* remote_name, wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2026-02-26 14:32:50 +01:00
|
|
|
struct synthetic_file* file = nullptr;
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
WINPR_ASSERT(local_name);
|
|
|
|
|
WINPR_ASSERT(remote_name);
|
|
|
|
|
WINPR_ASSERT(files);
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
file = make_synthetic_file(local_name, remote_name);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!file)
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2021-05-17 12:30:18 +02:00
|
|
|
if (!ArrayList_Append(files, file))
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
free_synthetic_file(file);
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
if (file->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* This is effectively a recursive call, but we do not track
|
|
|
|
|
* recursion depth, thus filesystem loops can cause a crash.
|
|
|
|
|
*/
|
2022-07-06 12:00:16 +02:00
|
|
|
if (!add_directory_contents_to_list(clipboard, local_name, remote_name, files))
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static const WCHAR* get_basename(const WCHAR* name)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
const WCHAR* c = name;
|
|
|
|
|
const WCHAR* last_name = name;
|
2022-09-26 13:31:06 +02:00
|
|
|
const WCHAR slash = '/';
|
|
|
|
|
|
|
|
|
|
WINPR_ASSERT(name);
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
while (*c++)
|
|
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
if (*c == slash)
|
2017-04-09 02:29:51 +03:00
|
|
|
last_name = c + 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return last_name;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL process_file_name(wClipboard* clipboard, const WCHAR* local_name, wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2017-04-09 02:29:51 +03:00
|
|
|
BOOL result = FALSE;
|
2026-02-26 14:32:50 +01:00
|
|
|
const WCHAR* base_name = nullptr;
|
|
|
|
|
WCHAR* remote_name = nullptr;
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
WINPR_ASSERT(local_name);
|
|
|
|
|
WINPR_ASSERT(files);
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
2017-07-03 19:57:41 +02:00
|
|
|
base_name = get_basename(local_name);
|
2022-07-06 12:00:16 +02:00
|
|
|
remote_name = convert_local_name_component_to_remote(clipboard, base_name);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:52 +03:00
|
|
|
if (!remote_name)
|
|
|
|
|
return FALSE;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-07-06 12:00:16 +02:00
|
|
|
result = add_file_to_list(clipboard, local_name, remote_name, files);
|
2017-04-09 02:29:51 +03:00
|
|
|
free(remote_name);
|
|
|
|
|
return result;
|
2017-04-09 02:29:51 +03:00
|
|
|
}
|
|
|
|
|
|
2022-09-16 11:23:21 +08:00
|
|
|
static BOOL process_uri(wClipboard* clipboard, const char* uri, size_t uri_len)
|
|
|
|
|
{
|
|
|
|
|
// URI is specified by RFC 8089: https://datatracker.ietf.org/doc/html/rfc8089
|
|
|
|
|
BOOL result = FALSE;
|
2026-02-26 14:32:50 +01:00
|
|
|
char* name = nullptr;
|
2022-09-16 11:23:21 +08:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
|
2023-10-10 16:50:54 +02:00
|
|
|
name = parse_uri_to_local_file(uri, uri_len);
|
2022-09-16 11:23:21 +08:00
|
|
|
if (name)
|
|
|
|
|
{
|
2026-02-26 14:32:50 +01:00
|
|
|
WCHAR* wname = nullptr;
|
2022-09-09 09:25:13 +08:00
|
|
|
/*
|
|
|
|
|
* Note that local file names are not actually guaranteed to be
|
|
|
|
|
* encoded in UTF-8. Filesystems and users can use whatever they
|
|
|
|
|
* want. The OS does not care, aside from special treatment of
|
|
|
|
|
* '\0' and '/' bytes. But we need to make some decision here.
|
|
|
|
|
* Assuming UTF-8 is currently the most sane thing.
|
|
|
|
|
*/
|
2026-02-26 14:32:50 +01:00
|
|
|
wname = ConvertUtf8ToWCharAlloc(name, nullptr);
|
2022-10-28 08:09:27 +02:00
|
|
|
if (wname)
|
2022-09-09 09:25:13 +08:00
|
|
|
result = process_file_name(clipboard, wname, clipboard->localFiles);
|
2022-10-28 08:09:27 +02:00
|
|
|
|
2022-09-16 11:23:21 +08:00
|
|
|
free(name);
|
2022-09-09 09:25:13 +08:00
|
|
|
free(wname);
|
2022-09-16 11:23:21 +08:00
|
|
|
}
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-13 12:08:46 +02:00
|
|
|
static BOOL process_uri_list(wClipboard* clipboard, const char* data, size_t length)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2017-04-09 02:29:51 +03:00
|
|
|
const char* cur = data;
|
|
|
|
|
const char* lim = data + length;
|
2022-09-13 12:08:46 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
2022-09-26 13:31:06 +02:00
|
|
|
WINPR_ASSERT(data);
|
2022-09-13 12:08:46 +02:00
|
|
|
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_VRB(TAG, "processing URI list:\n%.*s", WINPR_ASSERTING_INT_CAST(int, length), data);
|
2022-09-13 12:08:46 +02:00
|
|
|
ArrayList_Clear(clipboard->localFiles);
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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 == '#');
|
2024-01-30 10:25:38 +01:00
|
|
|
const char* start = cur;
|
|
|
|
|
const char* stop = cur;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2024-01-30 10:25:38 +01:00
|
|
|
for (; stop < lim; stop++)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
if (*stop == '\r')
|
|
|
|
|
{
|
|
|
|
|
if ((stop + 1 < lim) && (*(stop + 1) == '\n'))
|
|
|
|
|
cur = stop + 2;
|
|
|
|
|
else
|
|
|
|
|
cur = stop + 1;
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
break;
|
|
|
|
|
}
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (*stop == '\n')
|
|
|
|
|
{
|
|
|
|
|
cur = stop + 1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (stop == lim)
|
2023-02-27 15:28:27 +01:00
|
|
|
{
|
2024-12-19 11:17:53 +01:00
|
|
|
if (strnlen(start, WINPR_ASSERTING_INT_CAST(size_t, stop - start)) < 1)
|
2023-02-27 15:28:27 +01:00
|
|
|
return TRUE;
|
2017-04-09 02:29:51 +03:00
|
|
|
cur = lim;
|
2023-02-27 15:28:27 +01:00
|
|
|
}
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
if (comment)
|
|
|
|
|
continue;
|
|
|
|
|
|
2024-12-19 11:17:53 +01:00
|
|
|
if (!process_uri(clipboard, start, WINPR_ASSERTING_INT_CAST(size_t, stop - start)))
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static BOOL convert_local_file_to_filedescriptor(const struct synthetic_file* file,
|
2020-09-17 15:21:45 +02:00
|
|
|
FILEDESCRIPTORW* descriptor)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
|
|
|
|
size_t remote_len = 0;
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
WINPR_ASSERT(file);
|
|
|
|
|
WINPR_ASSERT(descriptor);
|
|
|
|
|
|
2020-12-30 02:17:43 +01:00
|
|
|
descriptor->dwFlags = FD_ATTRIBUTES | FD_FILESIZE | FD_WRITESTIME | FD_PROGRESSUI;
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
if (file->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
|
|
|
|
descriptor->dwFileAttributes = FILE_ATTRIBUTE_DIRECTORY;
|
|
|
|
|
descriptor->nFileSizeLow = 0;
|
|
|
|
|
descriptor->nFileSizeHigh = 0;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
descriptor->dwFileAttributes = FILE_ATTRIBUTE_NORMAL;
|
2022-09-09 09:25:13 +08:00
|
|
|
descriptor->nFileSizeLow = file->nFileSizeLow;
|
|
|
|
|
descriptor->nFileSizeHigh = file->nFileSizeHigh;
|
2017-04-09 02:29:50 +03:00
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
descriptor->ftLastWriteTime = file->ftLastWriteTime;
|
2020-12-30 02:17:43 +01:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
remote_len = _wcsnlen(file->remote_name, ARRAYSIZE(descriptor->cFileName));
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
if (remote_len >= ARRAYSIZE(descriptor->cFileName))
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2019-11-06 15:24:51 +01:00
|
|
|
WLog_ERR(TAG, "file name too long (%" PRIuz " characters)", remote_len);
|
2017-04-09 02:29:50 +03:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-21 14:13:52 +03:00
|
|
|
memcpy(descriptor->cFileName, file->remote_name, remote_len * sizeof(WCHAR));
|
2017-04-09 02:29:50 +03:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-17 15:21:45 +02:00
|
|
|
static FILEDESCRIPTORW* convert_local_file_list_to_filedescriptors(wArrayList* files)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
size_t count = 0;
|
2026-02-26 14:32:50 +01:00
|
|
|
FILEDESCRIPTORW* descriptors = nullptr;
|
2022-09-26 13:31:06 +02:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
count = ArrayList_Count(files);
|
2022-09-26 13:31:06 +02:00
|
|
|
|
|
|
|
|
descriptors = calloc(count, sizeof(FILEDESCRIPTORW));
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!descriptors)
|
|
|
|
|
goto error;
|
|
|
|
|
|
2024-01-30 10:25:38 +01:00
|
|
|
for (size_t i = 0; i < count; i++)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
const struct synthetic_file* file = ArrayList_GetItem(files, i);
|
2017-04-09 02:29:50 +03:00
|
|
|
|
|
|
|
|
if (!convert_local_file_to_filedescriptor(file, &descriptors[i]))
|
|
|
|
|
goto error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return descriptors;
|
|
|
|
|
error:
|
|
|
|
|
free(descriptors);
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2017-04-09 02:29:50 +03:00
|
|
|
}
|
|
|
|
|
|
2025-02-13 15:28:27 +01:00
|
|
|
static void* convert_any_uri_list_to_filedescriptors(wClipboard* clipboard,
|
|
|
|
|
WINPR_ATTR_UNUSED UINT32 formatId,
|
2022-09-13 12:08:46 +02:00
|
|
|
UINT32* pSize)
|
|
|
|
|
{
|
2026-02-26 14:32:50 +01:00
|
|
|
FILEDESCRIPTORW* descriptors = nullptr;
|
2022-09-13 12:08:46 +02:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
WINPR_ASSERT(clipboard);
|
2022-09-13 12:08:46 +02:00
|
|
|
WINPR_ASSERT(pSize);
|
|
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
descriptors = convert_local_file_list_to_filedescriptors(clipboard->localFiles);
|
2022-09-13 12:08:46 +02:00
|
|
|
*pSize = 0;
|
|
|
|
|
if (!descriptors)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2022-09-13 12:08:46 +02:00
|
|
|
|
|
|
|
|
*pSize = (UINT32)ArrayList_Count(clipboard->localFiles) * sizeof(FILEDESCRIPTORW);
|
|
|
|
|
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
|
|
|
|
|
return descriptors;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
static void* convert_uri_list_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
|
2019-11-06 15:24:51 +01:00
|
|
|
const void* data, UINT32* pSize)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2022-09-13 12:08:46 +02:00
|
|
|
const UINT32 expected = ClipboardGetFormatId(clipboard, mime_uri_list);
|
|
|
|
|
if (formatId != expected)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2022-09-13 12:08:46 +02:00
|
|
|
if (!process_uri_list(clipboard, (const char*)data, *pSize))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2022-09-13 12:08:46 +02:00
|
|
|
return convert_any_uri_list_to_filedescriptors(clipboard, formatId, pSize);
|
|
|
|
|
}
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2022-09-13 12:08:46 +02:00
|
|
|
static BOOL process_files(wClipboard* clipboard, const char* data, UINT32 pSize, const char* prefix)
|
|
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
WINPR_ASSERT(prefix);
|
|
|
|
|
|
2022-09-13 12:08:46 +02:00
|
|
|
const size_t prefix_len = strlen(prefix);
|
|
|
|
|
|
|
|
|
|
WINPR_ASSERT(clipboard);
|
|
|
|
|
|
|
|
|
|
ArrayList_Clear(clipboard->localFiles);
|
|
|
|
|
|
|
|
|
|
if (!data || (pSize < prefix_len))
|
|
|
|
|
return FALSE;
|
|
|
|
|
if (strncmp(data, prefix, prefix_len) != 0)
|
|
|
|
|
return FALSE;
|
|
|
|
|
data += prefix_len;
|
2025-03-11 11:29:18 +01:00
|
|
|
if (pSize < prefix_len)
|
|
|
|
|
return FALSE;
|
|
|
|
|
pSize -= WINPR_ASSERTING_INT_CAST(uint32_t, prefix_len);
|
2022-09-13 12:08:46 +02:00
|
|
|
|
|
|
|
|
BOOL rc = FALSE;
|
|
|
|
|
char* copy = strndup(data, pSize);
|
|
|
|
|
if (!copy)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
|
|
{
|
2026-02-26 14:32:50 +01:00
|
|
|
char* endptr = nullptr;
|
2026-01-08 10:32:31 +01:00
|
|
|
char* tok = strtok_s(copy, "\n", &endptr);
|
|
|
|
|
while (tok)
|
|
|
|
|
{
|
|
|
|
|
const size_t tok_len = strnlen(tok, pSize);
|
|
|
|
|
if (!process_uri(clipboard, tok, tok_len))
|
|
|
|
|
goto fail;
|
|
|
|
|
if (pSize < tok_len)
|
|
|
|
|
goto fail;
|
|
|
|
|
pSize -= WINPR_ASSERTING_INT_CAST(uint32_t, tok_len);
|
2026-02-26 14:32:50 +01:00
|
|
|
tok = strtok_s(nullptr, "\n", &endptr);
|
2026-01-08 10:32:31 +01:00
|
|
|
}
|
2022-09-13 12:08:46 +02:00
|
|
|
}
|
2026-01-08 10:32:31 +01:00
|
|
|
|
2022-09-13 12:08:46 +02:00
|
|
|
rc = TRUE;
|
|
|
|
|
|
|
|
|
|
fail:
|
|
|
|
|
free(copy);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static BOOL process_gnome_copied_files(wClipboard* clipboard, const char* data, UINT32 pSize)
|
|
|
|
|
{
|
|
|
|
|
return process_files(clipboard, data, pSize, "copy\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static BOOL process_mate_copied_files(wClipboard* clipboard, const char* data, UINT32 pSize)
|
|
|
|
|
{
|
|
|
|
|
return process_files(clipboard, data, pSize, "copy\n");
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-21 15:46:21 +01:00
|
|
|
static void* convert_gnome_copied_files_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
|
|
|
|
|
const void* data, UINT32* pSize)
|
|
|
|
|
{
|
|
|
|
|
const UINT32 expected = ClipboardGetFormatId(clipboard, mime_gnome_copied_files);
|
|
|
|
|
if (formatId != expected)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2023-02-21 15:46:21 +01:00
|
|
|
if (!process_gnome_copied_files(clipboard, (const char*)data, *pSize))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2023-02-21 15:46:21 +01:00
|
|
|
return convert_any_uri_list_to_filedescriptors(clipboard, formatId, pSize);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void* convert_mate_copied_files_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
|
|
|
|
|
const void* data, UINT32* pSize)
|
|
|
|
|
{
|
|
|
|
|
const UINT32 expected = ClipboardGetFormatId(clipboard, mime_mate_copied_files);
|
|
|
|
|
if (formatId != expected)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2023-02-21 15:46:21 +01:00
|
|
|
|
|
|
|
|
if (!process_mate_copied_files(clipboard, (const char*)data, *pSize))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2023-02-21 15:46:21 +01:00
|
|
|
|
|
|
|
|
return convert_any_uri_list_to_filedescriptors(clipboard, formatId, pSize);
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-08 21:53:28 +08:00
|
|
|
static size_t count_special_chars(const WCHAR* str)
|
|
|
|
|
{
|
|
|
|
|
size_t count = 0;
|
2022-09-26 13:31:06 +02:00
|
|
|
const WCHAR* start = str;
|
|
|
|
|
|
|
|
|
|
WINPR_ASSERT(str);
|
2021-01-08 21:53:28 +08:00
|
|
|
while (*start)
|
|
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
const WCHAR sharp = '#';
|
|
|
|
|
const WCHAR questionmark = '?';
|
|
|
|
|
const WCHAR star = '*';
|
|
|
|
|
const WCHAR exclamationmark = '!';
|
|
|
|
|
const WCHAR percent = '%';
|
|
|
|
|
|
|
|
|
|
if ((*start == sharp) || (*start == questionmark) || (*start == star) ||
|
|
|
|
|
(*start == exclamationmark) || (*start == percent))
|
2021-01-08 21:53:28 +08:00
|
|
|
{
|
|
|
|
|
count++;
|
|
|
|
|
}
|
|
|
|
|
start++;
|
|
|
|
|
}
|
|
|
|
|
return count;
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-02 12:13:34 +02:00
|
|
|
static const char* stop_at_special_chars(const char* str)
|
2021-01-08 21:53:28 +08:00
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
const char* start = str;
|
|
|
|
|
WINPR_ASSERT(str);
|
|
|
|
|
|
2021-01-08 21:53:28 +08:00
|
|
|
while (*start)
|
|
|
|
|
{
|
|
|
|
|
if (*start == '#' || *start == '?' || *start == '*' || *start == '!' || *start == '%')
|
|
|
|
|
{
|
|
|
|
|
return start;
|
|
|
|
|
}
|
|
|
|
|
start++;
|
|
|
|
|
}
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2021-01-08 21:53:28 +08:00
|
|
|
}
|
|
|
|
|
|
2020-12-31 20:42:16 +08:00
|
|
|
/* The universal converter from filedescriptors to different file lists */
|
|
|
|
|
static void* convert_filedescriptors_to_file_list(wClipboard* clipboard, UINT32 formatId,
|
|
|
|
|
const void* data, UINT32* pSize,
|
|
|
|
|
const char* header, const char* lineprefix,
|
2021-08-09 11:48:19 +02:00
|
|
|
const char* lineending, BOOL skip_last_lineending)
|
2019-02-20 17:05:47 +01:00
|
|
|
{
|
2023-12-12 10:24:19 +01:00
|
|
|
union
|
|
|
|
|
{
|
|
|
|
|
char c[2];
|
|
|
|
|
WCHAR w;
|
|
|
|
|
} backslash;
|
|
|
|
|
backslash.c[0] = '\\';
|
|
|
|
|
backslash.c[1] = '\0';
|
|
|
|
|
|
2026-02-26 14:32:50 +01:00
|
|
|
const FILEDESCRIPTORW* descriptors = nullptr;
|
2019-05-08 14:41:22 +02:00
|
|
|
UINT32 nrDescriptors = 0;
|
2024-01-23 16:49:54 +01:00
|
|
|
size_t count = 0;
|
|
|
|
|
size_t alloc = 0;
|
|
|
|
|
size_t pos = 0;
|
2024-01-23 16:49:54 +01:00
|
|
|
size_t baseLength = 0;
|
2026-02-26 14:32:50 +01:00
|
|
|
char* dst = nullptr;
|
2020-12-31 20:42:16 +08:00
|
|
|
size_t header_len = strlen(header);
|
|
|
|
|
size_t lineprefix_len = strlen(lineprefix);
|
|
|
|
|
size_t lineending_len = strlen(lineending);
|
2024-01-23 16:49:54 +01:00
|
|
|
size_t decoration_len = 0;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
|
|
|
|
if (!clipboard || !data || !pSize)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
|
|
|
|
if (*pSize < sizeof(UINT32))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
|
|
|
|
if (clipboard->delegate.basePath)
|
|
|
|
|
baseLength = strnlen(clipboard->delegate.basePath, MAX_PATH);
|
|
|
|
|
|
|
|
|
|
if (baseLength < 1)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2026-02-24 20:18:25 +01:00
|
|
|
wStream sbuffer = WINPR_C_ARRAY_INIT;
|
2023-02-28 21:22:49 +01:00
|
|
|
wStream* s = Stream_StaticConstInit(&sbuffer, data, *pSize);
|
|
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 4))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2023-02-28 21:22:49 +01:00
|
|
|
|
|
|
|
|
Stream_Read_UINT32(s, nrDescriptors);
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2020-09-17 15:21:45 +02:00
|
|
|
count = (*pSize - 4) / sizeof(FILEDESCRIPTORW);
|
2019-02-20 17:05:47 +01:00
|
|
|
|
|
|
|
|
if ((count < 1) || (count != nrDescriptors))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2023-06-07 15:38:21 +02:00
|
|
|
descriptors = Stream_ConstPointer(s);
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2022-09-13 12:08:46 +02:00
|
|
|
if (formatId != ClipboardGetFormatId(clipboard, mime_FileGroupDescriptorW))
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2020-12-31 20:42:16 +08:00
|
|
|
/* Plus 1 for '/' between basepath and filename*/
|
|
|
|
|
decoration_len = lineprefix_len + lineending_len + baseLength + 1;
|
|
|
|
|
alloc = header_len;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2020-12-27 14:08:35 +08:00
|
|
|
/* Get total size of file/folder names under first level folder only */
|
2024-01-30 10:25:38 +01:00
|
|
|
for (size_t x = 0; x < count; x++)
|
2020-12-27 14:08:35 +08:00
|
|
|
{
|
2022-10-28 08:09:27 +02:00
|
|
|
const FILEDESCRIPTORW* dsc = &descriptors[x];
|
|
|
|
|
|
2026-02-26 14:32:50 +01:00
|
|
|
if (_wcschr(dsc->cFileName, backslash.w) == nullptr)
|
2020-12-27 14:08:35 +08:00
|
|
|
{
|
2022-10-28 08:09:27 +02:00
|
|
|
alloc += ARRAYSIZE(dsc->cFileName) *
|
|
|
|
|
8; /* Overallocate, just take the biggest value the result path can have */
|
|
|
|
|
/* # (1 char) -> %23 (3 chars) , the first char is replaced inplace */
|
2026-02-17 12:05:42 +01:00
|
|
|
alloc += count_special_chars(dsc->cFileName) * sizeof(WCHAR);
|
2022-03-28 15:44:58 +02:00
|
|
|
alloc += decoration_len;
|
2020-12-27 14:08:35 +08:00
|
|
|
}
|
|
|
|
|
}
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2020-12-27 14:08:35 +08:00
|
|
|
/* Append a prefix file:// and postfix \n for each file */
|
|
|
|
|
/* We need to keep last \n since snprintf is null terminated!! */
|
|
|
|
|
alloc++;
|
2019-02-20 17:05:47 +01:00
|
|
|
dst = calloc(alloc, sizeof(char));
|
|
|
|
|
|
|
|
|
|
if (!dst)
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2024-08-26 15:39:33 +02:00
|
|
|
(void)_snprintf(&dst[0], alloc, "%s", header);
|
2020-12-31 20:42:16 +08:00
|
|
|
|
|
|
|
|
pos = header_len;
|
2019-02-20 17:05:47 +01:00
|
|
|
|
2024-01-30 10:25:38 +01:00
|
|
|
for (size_t x = 0; x < count; x++)
|
2019-02-20 17:05:47 +01:00
|
|
|
{
|
2022-10-28 08:09:27 +02:00
|
|
|
const FILEDESCRIPTORW* dsc = &descriptors[x];
|
2022-04-28 10:49:42 +02:00
|
|
|
BOOL fail = TRUE;
|
2026-02-26 14:32:50 +01:00
|
|
|
if (_wcschr(dsc->cFileName, backslash.w) != nullptr)
|
2020-12-27 14:08:35 +08:00
|
|
|
{
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2022-10-28 08:09:27 +02:00
|
|
|
int rc = -1;
|
2026-02-24 20:18:25 +01:00
|
|
|
char curName[520] = WINPR_C_ARRAY_INIT;
|
2026-02-26 14:32:50 +01:00
|
|
|
const char* stop_at = nullptr;
|
|
|
|
|
const char* previous_at = nullptr;
|
2022-10-28 08:09:27 +02:00
|
|
|
|
|
|
|
|
if (ConvertWCharNToUtf8(dsc->cFileName, ARRAYSIZE(dsc->cFileName), curName,
|
|
|
|
|
ARRAYSIZE(curName)) < 0)
|
2022-04-28 10:49:42 +02:00
|
|
|
goto loop_fail;
|
2019-05-08 14:41:22 +02:00
|
|
|
|
2021-01-08 21:53:28 +08:00
|
|
|
rc = _snprintf(&dst[pos], alloc - pos, "%s%s/", lineprefix, clipboard->delegate.basePath);
|
2019-05-08 14:41:22 +02:00
|
|
|
|
|
|
|
|
if (rc < 0)
|
2022-04-28 10:49:42 +02:00
|
|
|
goto loop_fail;
|
|
|
|
|
|
2021-01-08 21:53:28 +08:00
|
|
|
pos += (size_t)rc;
|
|
|
|
|
|
|
|
|
|
previous_at = curName;
|
2026-02-26 14:32:50 +01:00
|
|
|
while ((stop_at = stop_at_special_chars(previous_at)) != nullptr)
|
2021-01-08 21:53:28 +08:00
|
|
|
{
|
2025-03-26 19:41:39 +01:00
|
|
|
const intptr_t diff = stop_at - previous_at;
|
|
|
|
|
if (diff < 0)
|
|
|
|
|
goto loop_fail;
|
|
|
|
|
char* tmp = strndup(previous_at, WINPR_ASSERTING_INT_CAST(size_t, diff));
|
2021-01-08 21:53:28 +08:00
|
|
|
if (!tmp)
|
2022-04-28 10:49:42 +02:00
|
|
|
goto loop_fail;
|
|
|
|
|
|
2025-03-26 19:41:39 +01:00
|
|
|
rc = _snprintf(&dst[pos], WINPR_ASSERTING_INT_CAST(size_t, diff + 1), "%s", tmp);
|
2021-01-08 21:53:28 +08:00
|
|
|
free(tmp);
|
|
|
|
|
if (rc < 0)
|
2022-04-28 10:49:42 +02:00
|
|
|
goto loop_fail;
|
|
|
|
|
|
2021-01-08 21:53:28 +08:00
|
|
|
pos += (size_t)rc;
|
|
|
|
|
rc = _snprintf(&dst[pos], 4, "%%%x", *stop_at);
|
|
|
|
|
if (rc < 0)
|
2022-04-28 10:49:42 +02:00
|
|
|
goto loop_fail;
|
|
|
|
|
|
2021-01-08 21:53:28 +08:00
|
|
|
pos += (size_t)rc;
|
|
|
|
|
previous_at = stop_at + 1;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-28 15:44:58 +02:00
|
|
|
rc = _snprintf(&dst[pos], alloc - pos, "%s%s", previous_at, lineending);
|
2021-08-09 11:48:19 +02:00
|
|
|
|
2022-04-28 10:49:42 +02:00
|
|
|
fail = FALSE;
|
|
|
|
|
loop_fail:
|
|
|
|
|
if ((rc < 0) || fail)
|
2021-01-08 21:53:28 +08:00
|
|
|
{
|
|
|
|
|
free(dst);
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2021-01-08 21:53:28 +08:00
|
|
|
}
|
2019-05-08 14:41:22 +02:00
|
|
|
|
|
|
|
|
pos += (size_t)rc;
|
2019-02-20 17:05:47 +01:00
|
|
|
}
|
|
|
|
|
|
2022-03-28 15:44:58 +02:00
|
|
|
if (skip_last_lineending)
|
|
|
|
|
{
|
|
|
|
|
const size_t endlen = strlen(lineending);
|
|
|
|
|
if (alloc > endlen)
|
|
|
|
|
{
|
2023-02-21 14:47:20 +01:00
|
|
|
const size_t len = strnlen(dst, alloc);
|
|
|
|
|
if (len < endlen)
|
2022-03-28 15:44:58 +02:00
|
|
|
{
|
2023-02-21 14:47:20 +01:00
|
|
|
free(dst);
|
2026-02-26 14:32:50 +01:00
|
|
|
return nullptr;
|
2023-02-21 14:47:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (memcmp(&dst[len - endlen], lineending, endlen) == 0)
|
|
|
|
|
{
|
|
|
|
|
memset(&dst[len - endlen], 0, endlen);
|
2022-03-28 15:44:58 +02:00
|
|
|
alloc -= endlen;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-02-23 21:28:33 +01:00
|
|
|
|
|
|
|
|
alloc = strnlen(dst, alloc) + 1;
|
2019-05-08 14:41:22 +02:00
|
|
|
*pSize = (UINT32)alloc;
|
2019-02-20 17:05:47 +01:00
|
|
|
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
|
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 12:51:32 +08:00
|
|
|
/* Prepend header of kde dolphin format to file list
|
|
|
|
|
* See:
|
|
|
|
|
* GTK: https://docs.gtk.org/glib/struct.Uri.html
|
|
|
|
|
* uri syntax: https://www.rfc-editor.org/rfc/rfc3986#section-3
|
|
|
|
|
* uri-lists format: https://www.rfc-editor.org/rfc/rfc2483#section-5
|
|
|
|
|
*/
|
2020-12-31 20:42:16 +08:00
|
|
|
static void* convert_filedescriptors_to_uri_list(wClipboard* clipboard, UINT32 formatId,
|
|
|
|
|
const void* data, UINT32* pSize)
|
|
|
|
|
{
|
2023-02-21 14:47:20 +01:00
|
|
|
return convert_filedescriptors_to_file_list(clipboard, formatId, data, pSize, "", "file://",
|
|
|
|
|
"\r\n", FALSE);
|
2020-12-31 20:42:16 +08:00
|
|
|
}
|
|
|
|
|
|
2020-12-27 14:08:35 +08:00
|
|
|
/* Prepend header of common gnome format to file list*/
|
|
|
|
|
static void* convert_filedescriptors_to_gnome_copied_files(wClipboard* clipboard, UINT32 formatId,
|
|
|
|
|
const void* data, UINT32* pSize)
|
|
|
|
|
{
|
2020-12-31 20:42:16 +08:00
|
|
|
return convert_filedescriptors_to_file_list(clipboard, formatId, data, pSize, "copy\n",
|
2021-08-09 11:48:19 +02:00
|
|
|
"file://", "\n", TRUE);
|
2020-12-27 14:08:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void* convert_filedescriptors_to_mate_copied_files(wClipboard* clipboard, UINT32 formatId,
|
|
|
|
|
const void* data, UINT32* pSize)
|
|
|
|
|
{
|
2020-12-31 20:42:16 +08:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
char* pDstData = convert_filedescriptors_to_file_list(clipboard, formatId, data, pSize,
|
2023-02-24 09:40:35 +01:00
|
|
|
"copy\n", "file://", "\n", TRUE);
|
2020-12-27 14:08:35 +08:00
|
|
|
if (!pDstData)
|
|
|
|
|
{
|
|
|
|
|
return pDstData;
|
|
|
|
|
}
|
2020-12-31 20:42:16 +08:00
|
|
|
/* Replace last \n with \0
|
2020-12-27 14:08:35 +08:00
|
|
|
see
|
|
|
|
|
mate-desktop/caja/libcaja-private/caja-clipboard.c:caja_clipboard_get_uri_list_from_selection_data
|
|
|
|
|
*/
|
2020-12-31 20:42:16 +08:00
|
|
|
|
|
|
|
|
pDstData[*pSize - 1] = '\0';
|
|
|
|
|
*pSize = *pSize - 1;
|
|
|
|
|
return pDstData;
|
2020-12-27 14:08:35 +08:00
|
|
|
}
|
|
|
|
|
|
2022-10-27 14:13:00 +02:00
|
|
|
static void array_free_synthetic_file(void* the_file)
|
|
|
|
|
{
|
|
|
|
|
struct synthetic_file* file = the_file;
|
|
|
|
|
free_synthetic_file(file);
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
static BOOL register_file_formats_and_synthesizers(wClipboard* clipboard)
|
|
|
|
|
{
|
2026-02-26 14:32:50 +01:00
|
|
|
wObject* obj = nullptr;
|
2023-02-21 15:46:21 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
1. Gnome Nautilus based file manager (Nautilus only with version >= 3.30 AND < 40):
|
|
|
|
|
TARGET: UTF8_STRING
|
|
|
|
|
format: x-special/nautilus-clipboard\copy\n\file://path\n\0
|
|
|
|
|
2. Kde Dolpin and Qt:
|
|
|
|
|
TARGET: text/uri-list
|
|
|
|
|
format: file:path\r\n\0
|
|
|
|
|
See:
|
|
|
|
|
GTK: https://docs.gtk.org/glib/struct.Uri.html
|
|
|
|
|
uri syntax: https://www.rfc-editor.org/rfc/rfc3986#section-3
|
2024-11-20 16:53:40 -05:00
|
|
|
uri-lists format: https://www.rfc-editor.org/rfc/rfc2483#section-5
|
2023-02-21 15:46:21 +01:00
|
|
|
3. Gnome and others (Unity/XFCE/Nautilus < 3.30/Nautilus >= 40):
|
|
|
|
|
TARGET: x-special/gnome-copied-files
|
|
|
|
|
format: copy\nfile://path\n\0
|
|
|
|
|
4. Mate Caja:
|
|
|
|
|
TARGET: x-special/mate-copied-files
|
|
|
|
|
format: copy\nfile://path\n
|
|
|
|
|
|
|
|
|
|
TODO: other file managers do not use previous targets and formats.
|
|
|
|
|
*/
|
2020-12-27 14:08:35 +08:00
|
|
|
|
2023-02-24 09:40:35 +01:00
|
|
|
const UINT32 local_gnome_file_format_id =
|
|
|
|
|
ClipboardRegisterFormat(clipboard, mime_gnome_copied_files);
|
|
|
|
|
const UINT32 local_mate_file_format_id =
|
|
|
|
|
ClipboardRegisterFormat(clipboard, mime_mate_copied_files);
|
|
|
|
|
const UINT32 file_group_format_id =
|
|
|
|
|
ClipboardRegisterFormat(clipboard, mime_FileGroupDescriptorW);
|
|
|
|
|
const UINT32 local_file_format_id = ClipboardRegisterFormat(clipboard, mime_uri_list);
|
2020-12-27 14:08:35 +08:00
|
|
|
|
2023-02-21 15:46:21 +01:00
|
|
|
if (!file_group_format_id || !local_file_format_id || !local_gnome_file_format_id ||
|
|
|
|
|
!local_mate_file_format_id)
|
2017-04-09 02:29:50 +03:00
|
|
|
goto error;
|
|
|
|
|
|
|
|
|
|
clipboard->localFiles = ArrayList_New(FALSE);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!clipboard->localFiles)
|
|
|
|
|
goto error;
|
|
|
|
|
|
2020-05-12 17:16:14 +02:00
|
|
|
obj = ArrayList_Object(clipboard->localFiles);
|
2022-10-27 14:13:00 +02:00
|
|
|
obj->fnObjectFree = array_free_synthetic_file;
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2019-11-06 15:24:51 +01:00
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, local_file_format_id, file_group_format_id,
|
2017-11-14 13:57:00 +01:00
|
|
|
convert_uri_list_to_filedescriptors))
|
2017-04-09 02:29:50 +03:00
|
|
|
goto error_free_local_files;
|
|
|
|
|
|
2019-11-06 15:24:51 +01:00
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_file_format_id,
|
2019-02-20 17:05:47 +01:00
|
|
|
convert_filedescriptors_to_uri_list))
|
|
|
|
|
goto error_free_local_files;
|
2023-02-21 15:46:21 +01:00
|
|
|
|
|
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, local_gnome_file_format_id, file_group_format_id,
|
|
|
|
|
convert_gnome_copied_files_to_filedescriptors))
|
|
|
|
|
goto error_free_local_files;
|
|
|
|
|
|
|
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_gnome_file_format_id,
|
|
|
|
|
convert_filedescriptors_to_gnome_copied_files))
|
|
|
|
|
goto error_free_local_files;
|
|
|
|
|
|
|
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, local_mate_file_format_id, file_group_format_id,
|
|
|
|
|
convert_mate_copied_files_to_filedescriptors))
|
|
|
|
|
goto error_free_local_files;
|
|
|
|
|
|
|
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_mate_file_format_id,
|
|
|
|
|
convert_filedescriptors_to_mate_copied_files))
|
|
|
|
|
goto error_free_local_files;
|
2020-12-27 14:08:35 +08:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
return TRUE;
|
|
|
|
|
error_free_local_files:
|
|
|
|
|
ArrayList_Free(clipboard->localFiles);
|
2026-02-26 14:32:50 +01:00
|
|
|
clipboard->localFiles = nullptr;
|
2017-04-09 02:29:50 +03:00
|
|
|
error:
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-19 11:17:53 +01:00
|
|
|
static int32_t file_get_size(const struct synthetic_file* file, UINT64* size)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
UINT64 s = 0;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
if (!file || !size)
|
|
|
|
|
return E_INVALIDARG;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
s = file->nFileSizeHigh;
|
|
|
|
|
s <<= 32;
|
|
|
|
|
s |= file->nFileSizeLow;
|
|
|
|
|
*size = s;
|
2017-04-09 02:29:51 +03:00
|
|
|
return NO_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static UINT delegate_file_request_size(wClipboardDelegate* delegate,
|
|
|
|
|
const wClipboardFileSizeRequest* request)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
UINT64 size = 0;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
if (!delegate || !delegate->clipboard || !request)
|
|
|
|
|
return ERROR_BAD_ARGUMENTS;
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (delegate->clipboard->sequenceNumber != delegate->clipboard->fileListSequenceNumber)
|
|
|
|
|
return ERROR_INVALID_STATE;
|
|
|
|
|
|
2025-02-10 13:00:48 +01:00
|
|
|
struct synthetic_file* file =
|
|
|
|
|
ArrayList_GetItem(delegate->clipboard->localFiles, request->listIndex);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!file)
|
|
|
|
|
return ERROR_INDEX_ABSENT;
|
|
|
|
|
|
2025-02-10 13:00:48 +01:00
|
|
|
const int32_t s = file_get_size(file, &size);
|
|
|
|
|
uint32_t error = 0;
|
2017-04-09 02:29:51 +03:00
|
|
|
if (error)
|
2025-02-10 13:00:48 +01:00
|
|
|
error = delegate->ClipboardFileSizeFailure(delegate, request, (UINT)s);
|
2017-04-09 02:29:51 +03:00
|
|
|
else
|
|
|
|
|
error = delegate->ClipboardFileSizeSuccess(delegate, request, size);
|
|
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
|
WLog_WARN(TAG, "failed to report file size result: 0x%08X", error);
|
|
|
|
|
|
|
|
|
|
return NO_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
UINT synthetic_file_read_close(struct synthetic_file* file, BOOL force)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
if (!file || INVALID_HANDLE_VALUE == file->fd)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
return NO_ERROR;
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
/* Always force close the file. Clipboard might open hundreds of files
|
|
|
|
|
* so avoid caching to prevent running out of available file descriptors */
|
|
|
|
|
UINT64 size = 0;
|
|
|
|
|
file_get_size(file, &size);
|
2022-12-05 08:58:38 +01:00
|
|
|
if ((file->offset < 0) || ((UINT64)file->offset >= size) || force)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_VRB(TAG, "close file %p", file->fd);
|
2023-03-14 10:58:15 +01:00
|
|
|
if (!CloseHandle(file->fd))
|
2022-09-09 09:25:13 +08:00
|
|
|
{
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_WARN(TAG, "failed to close fd %p: %" PRIu32, file->fd, GetLastError());
|
2022-09-09 09:25:13 +08: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
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
file->fd = INVALID_HANDLE_VALUE;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NO_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static UINT file_get_range(struct synthetic_file* file, UINT64 offset, UINT32 size,
|
|
|
|
|
BYTE** actual_data, UINT32* actual_size)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
UINT error = NO_ERROR;
|
|
|
|
|
DWORD dwLow = 0;
|
|
|
|
|
DWORD dwHigh = 0;
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2022-09-26 13:31:06 +02:00
|
|
|
WINPR_ASSERT(file);
|
|
|
|
|
WINPR_ASSERT(actual_data);
|
|
|
|
|
WINPR_ASSERT(actual_size);
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
if (INVALID_HANDLE_VALUE == file->fd)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2026-02-24 20:18:25 +01:00
|
|
|
BY_HANDLE_FILE_INFORMATION FileInfo = WINPR_C_ARRAY_INIT;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2026-02-26 14:32:50 +01:00
|
|
|
file->fd = CreateFileW(file->local_name, GENERIC_READ, 0, nullptr, OPEN_EXISTING,
|
|
|
|
|
FILE_ATTRIBUTE_NORMAL, nullptr);
|
2022-09-09 09:25:13 +08:00
|
|
|
if (INVALID_HANDLE_VALUE == file->fd)
|
|
|
|
|
{
|
2026-02-24 20:18:25 +01:00
|
|
|
char name[MAX_PATH] = WINPR_C_ARRAY_INIT;
|
2026-01-16 11:42:46 +01:00
|
|
|
ConvertWCharToUtf8(file->local_name, name, sizeof(name) - 1);
|
2022-09-09 09:25:13 +08:00
|
|
|
error = GetLastError();
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_ERR(TAG, "failed to open file %s: 0x%08" PRIx32, name, error);
|
2022-09-09 09:25:13 +08:00
|
|
|
return error;
|
|
|
|
|
}
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
if (!GetFileInformationByHandle(file->fd, &FileInfo))
|
|
|
|
|
{
|
2026-02-24 20:18:25 +01:00
|
|
|
char name[MAX_PATH] = WINPR_C_ARRAY_INIT;
|
2026-01-16 11:42:46 +01:00
|
|
|
ConvertWCharToUtf8(file->local_name, name, sizeof(name) - 1);
|
2024-09-16 04:58:36 +02:00
|
|
|
(void)CloseHandle(file->fd);
|
2024-04-17 09:22:31 +02:00
|
|
|
file->fd = INVALID_HANDLE_VALUE;
|
2022-09-09 09:25:13 +08:00
|
|
|
error = GetLastError();
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_ERR(TAG, "Get file [%s] information fail: 0x%08" PRIx32, name, error);
|
2022-09-09 09:25:13 +08:00
|
|
|
return error;
|
|
|
|
|
}
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
file->offset = 0;
|
|
|
|
|
file->nFileSizeHigh = FileInfo.nFileSizeHigh;
|
|
|
|
|
file->nFileSizeLow = FileInfo.nFileSizeLow;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
/*
|
|
|
|
|
{
|
|
|
|
|
UINT64 s = 0;
|
|
|
|
|
file_get_size(file, &s);
|
|
|
|
|
WLog_DBG(TAG, "open file %d -> %s", file->fd, file->local_name);
|
|
|
|
|
WLog_DBG(TAG, "file %d size: %" PRIu64 " bytes", file->fd, s);
|
|
|
|
|
} //*/
|
|
|
|
|
}
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
do
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-09 09:25:13 +08:00
|
|
|
/*
|
|
|
|
|
* We should avoid seeking when possible as some filesystems (e.g.,
|
|
|
|
|
* an FTP server mapped via FUSE) may not support seeking. We keep
|
|
|
|
|
* an accurate account of the current file offset and do not call
|
|
|
|
|
* lseek() if the client requests file content sequentially.
|
|
|
|
|
*/
|
|
|
|
|
if (offset > INT64_MAX)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
2022-09-29 14:55:27 +02:00
|
|
|
WLog_ERR(TAG, "offset [%" PRIu64 "] > INT64_MAX", offset);
|
2022-09-09 09:25:13 +08:00
|
|
|
error = ERROR_SEEK;
|
|
|
|
|
break;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
}
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
if (file->offset != (INT64)offset)
|
|
|
|
|
{
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_DBG(TAG, "file %p force seeking to %" PRIu64 ", current %" PRId64, file->fd,
|
2022-09-09 09:25:13 +08: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
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
dwHigh = offset >> 32;
|
|
|
|
|
dwLow = offset & 0xFFFFFFFF;
|
2024-12-19 11:17:53 +01:00
|
|
|
if (INVALID_SET_FILE_POINTER == SetFilePointer(file->fd,
|
|
|
|
|
WINPR_ASSERTING_INT_CAST(LONG, dwLow),
|
|
|
|
|
(PLONG)&dwHigh, FILE_BEGIN))
|
2022-09-09 09:25:13 +08:00
|
|
|
{
|
|
|
|
|
error = GetLastError();
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-11-14 13:57:00 +01:00
|
|
|
|
2024-04-11 12:27:01 +02:00
|
|
|
BYTE* buffer = malloc(size);
|
2022-09-09 09:25:13 +08:00
|
|
|
if (!buffer)
|
|
|
|
|
{
|
|
|
|
|
error = ERROR_NOT_ENOUGH_MEMORY;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2026-02-26 14:32:50 +01:00
|
|
|
if (!ReadFile(file->fd, buffer, size, (LPDWORD)actual_size, nullptr))
|
2022-09-09 09:25:13 +08:00
|
|
|
{
|
2024-04-11 12:27:01 +02:00
|
|
|
free(buffer);
|
2022-09-09 09:25:13 +08:00
|
|
|
error = GetLastError();
|
|
|
|
|
break;
|
|
|
|
|
}
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
*actual_data = buffer;
|
|
|
|
|
file->offset += *actual_size;
|
2026-01-16 11:42:46 +01:00
|
|
|
WLog_VRB(TAG, "file %p actual read %" PRIu32 " bytes (offset %" PRId64 ")", file->fd,
|
2022-09-09 09:25:13 +08:00
|
|
|
*actual_size, file->offset);
|
|
|
|
|
} while (0);
|
2021-03-26 10:52:35 +01:00
|
|
|
|
2023-02-21 13:02:36 +01:00
|
|
|
synthetic_file_read_close(file, TRUE /* (error != NO_ERROR) && (size > 0) */);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
static UINT delegate_file_request_range(wClipboardDelegate* delegate,
|
|
|
|
|
const wClipboardFileRangeRequest* request)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
UINT error = 0;
|
2026-02-26 14:32:50 +01:00
|
|
|
BYTE* data = nullptr;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
UINT32 size = 0;
|
|
|
|
|
UINT64 offset = 0;
|
2026-02-26 14:32:50 +01:00
|
|
|
struct synthetic_file* file = nullptr;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
if (!delegate || !delegate->clipboard || !request)
|
|
|
|
|
return ERROR_BAD_ARGUMENTS;
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (delegate->clipboard->sequenceNumber != delegate->clipboard->fileListSequenceNumber)
|
|
|
|
|
return ERROR_INVALID_STATE;
|
|
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
file = ArrayList_GetItem(delegate->clipboard->localFiles, request->listIndex);
|
2017-11-14 13:57:00 +01:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (!file)
|
|
|
|
|
return ERROR_INDEX_ABSENT;
|
|
|
|
|
|
2019-11-06 15:24:51 +01:00
|
|
|
offset = (((UINT64)request->nPositionHigh) << 32) | ((UINT64)request->nPositionLow);
|
2022-09-09 09:25:13 +08:00
|
|
|
error = file_get_range(file, offset, request->cbRequested, &data, &size);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
|
error = delegate->ClipboardFileRangeFailure(delegate, request, error);
|
|
|
|
|
else
|
|
|
|
|
error = delegate->ClipboardFileRangeSuccess(delegate, request, data, size);
|
|
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
|
WLog_WARN(TAG, "failed to report file range result: 0x%08X", error);
|
|
|
|
|
|
|
|
|
|
free(data);
|
|
|
|
|
return NO_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-13 15:28:27 +01:00
|
|
|
static UINT dummy_file_size_success(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
|
|
|
|
|
WINPR_ATTR_UNUSED const wClipboardFileSizeRequest* request,
|
|
|
|
|
WINPR_ATTR_UNUSED UINT64 fileSize)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-13 15:28:27 +01:00
|
|
|
static UINT dummy_file_size_failure(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
|
|
|
|
|
WINPR_ATTR_UNUSED const wClipboardFileSizeRequest* request,
|
|
|
|
|
WINPR_ATTR_UNUSED UINT errorCode)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-13 15:28:27 +01:00
|
|
|
static UINT dummy_file_range_success(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
|
|
|
|
|
WINPR_ATTR_UNUSED const wClipboardFileRangeRequest* request,
|
|
|
|
|
WINPR_ATTR_UNUSED const BYTE* data,
|
|
|
|
|
WINPR_ATTR_UNUSED UINT32 size)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-13 15:28:27 +01:00
|
|
|
static UINT dummy_file_range_failure(WINPR_ATTR_UNUSED wClipboardDelegate* delegate,
|
|
|
|
|
WINPR_ATTR_UNUSED const wClipboardFileRangeRequest* request,
|
|
|
|
|
WINPR_ATTR_UNUSED UINT errorCode)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static void setup_delegate(wClipboardDelegate* delegate)
|
|
|
|
|
{
|
2022-09-26 13:31:06 +02:00
|
|
|
WINPR_ASSERT(delegate);
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
delegate->ClientRequestFileSize = delegate_file_request_size;
|
2017-04-09 02:29:51 +03:00
|
|
|
delegate->ClipboardFileSizeSuccess = dummy_file_size_success;
|
|
|
|
|
delegate->ClipboardFileSizeFailure = dummy_file_size_failure;
|
2022-09-09 09:25:13 +08:00
|
|
|
delegate->ClientRequestFileRange = delegate_file_request_range;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
delegate->ClipboardFileRangeSuccess = dummy_file_range_success;
|
|
|
|
|
delegate->ClipboardFileRangeFailure = dummy_file_range_failure;
|
2022-07-06 12:00:16 +02:00
|
|
|
delegate->IsFileNameComponentValid = ValidFileNameComponent;
|
2017-04-09 02:29:51 +03:00
|
|
|
}
|
|
|
|
|
|
2022-09-09 09:25:13 +08:00
|
|
|
BOOL ClipboardInitSyntheticFileSubsystem(wClipboard* clipboard)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
|
|
|
|
if (!clipboard)
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!register_file_formats_and_synthesizers(clipboard))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
setup_delegate(&clipboard->delegate);
|
2017-04-09 02:29:50 +03:00
|
|
|
return TRUE;
|
|
|
|
|
}
|