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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
#include "config.h"
|
|
|
|
#endif
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
#define _FILE_OFFSET_BITS 64
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdlib.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <errno.h>
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
#include <dirent.h>
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
#include <fcntl.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
2017-04-09 02:29:50 +03:00
|
|
|
|
2018-08-24 14:49:19 +03: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>
|
|
|
|
|
|
|
|
#include "clipboard.h"
|
|
|
|
#include "posix.h"
|
|
|
|
|
|
|
|
#include "../log.h"
|
|
|
|
#define TAG WINPR_TAG("clipboard.posix")
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
struct posix_file
|
|
|
|
{
|
|
|
|
char* local_name;
|
|
|
|
WCHAR* remote_name;
|
2017-04-09 02:29:50 +03:00
|
|
|
BOOL is_directory;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
int fd;
|
2017-08-11 11:07:46 +03:00
|
|
|
INT64 offset;
|
|
|
|
INT64 size;
|
2017-04-09 02:29:50 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct posix_file* make_posix_file(const char* local_name, const WCHAR* remote_name)
|
|
|
|
{
|
|
|
|
struct posix_file* file = NULL;
|
2017-04-09 02:29:50 +03:00
|
|
|
struct stat statbuf;
|
2017-04-09 02:29:50 +03:00
|
|
|
file = calloc(1, sizeof(*file));
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!file)
|
|
|
|
return NULL;
|
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
file->fd = -1;
|
|
|
|
file->offset = 0;
|
2017-04-09 02:29:50 +03:00
|
|
|
file->local_name = _strdup(local_name);
|
|
|
|
file->remote_name = _wcsdup(remote_name);
|
|
|
|
|
|
|
|
if (!file->local_name || !file->remote_name)
|
|
|
|
goto error;
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (stat(local_name, &statbuf))
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to stat %s: %s", local_name, strerror(err));
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
file->is_directory = S_ISDIR(statbuf.st_mode);
|
|
|
|
file->size = statbuf.st_size;
|
2017-04-09 02:29:50 +03:00
|
|
|
return file;
|
|
|
|
error:
|
|
|
|
free(file->local_name);
|
|
|
|
free(file->remote_name);
|
|
|
|
free(file);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_posix_file(void* the_file)
|
|
|
|
{
|
|
|
|
struct posix_file* file = the_file;
|
|
|
|
|
|
|
|
if (!file)
|
|
|
|
return;
|
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (file->fd >= 0)
|
|
|
|
{
|
|
|
|
if (close(file->fd) < 0)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_WARN(TAG, "failed to close fd %d: %s", file->fd, strerror(err));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
free(file->local_name);
|
|
|
|
free(file->remote_name);
|
|
|
|
free(file);
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static unsigned char hex_to_dec(char c, BOOL* valid)
|
|
|
|
{
|
|
|
|
if (('0' <= c) && (c <= '9'))
|
|
|
|
return (c - '0');
|
|
|
|
|
|
|
|
if (('a' <= c) && (c <= 'f'))
|
|
|
|
return (c - 'a') + 10;
|
|
|
|
|
|
|
|
if (('A' <= c) && (c <= 'F'))
|
|
|
|
return (c - 'A') + 10;
|
|
|
|
|
|
|
|
*valid = FALSE;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL decode_percent_encoded_byte(const char* str, const char* end, char* value)
|
|
|
|
{
|
|
|
|
BOOL valid = TRUE;
|
|
|
|
|
2019-02-07 16:34:37 +03:00
|
|
|
if ((end < str) || ((size_t)(end - str) < strlen("%20")))
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
*value = 0;
|
|
|
|
*value |= hex_to_dec(str[1], &valid);
|
|
|
|
*value <<= 4;
|
|
|
|
*value |= hex_to_dec(str[2], &valid);
|
|
|
|
return valid;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static char* decode_percent_encoded_string(const char* str, size_t len)
|
|
|
|
{
|
2017-04-09 02:29:51 +03:00
|
|
|
char* buffer = NULL;
|
|
|
|
char* next = NULL;
|
|
|
|
const char* cur = str;
|
|
|
|
const char* lim = str + len;
|
|
|
|
/* Percent decoding shrinks data length, so len bytes will be enough. */
|
|
|
|
buffer = calloc(len + 1, sizeof(char));
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!buffer)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
next = buffer;
|
|
|
|
|
|
|
|
while (cur < lim)
|
|
|
|
{
|
|
|
|
if (*cur != '%')
|
|
|
|
{
|
|
|
|
*next++ = *cur++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!decode_percent_encoded_byte(cur, lim, next))
|
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "invalid percent encoding");
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
cur += strlen("%20");
|
|
|
|
next += 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return buffer;
|
|
|
|
error:
|
|
|
|
free(buffer);
|
2017-04-09 02:29:51 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:52 +03:00
|
|
|
/*
|
|
|
|
* Note that the function converts a single file name component,
|
|
|
|
* it does not take care of component separators.
|
|
|
|
*/
|
|
|
|
static WCHAR* convert_local_name_component_to_remote(const char* local_name)
|
|
|
|
{
|
|
|
|
WCHAR* remote_name = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that local file names are not actually guaranteed to be
|
|
|
|
* encoded in UTF-8. Filesystems and users can use whatever they
|
|
|
|
* want. The OS does not care, aside from special treatment of
|
|
|
|
* '\0' and '/' bytes. But we need to make some decision here.
|
|
|
|
* Assuming UTF-8 is currently the most sane thing.
|
|
|
|
*/
|
|
|
|
if (!ConvertToUnicode(CP_UTF8, 0, local_name, -1, &remote_name, 0))
|
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "Unicode conversion failed for %s", local_name);
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some file names are not valid on Windows. Check for these now
|
|
|
|
* so that we won't get ourselves into a trouble later as such names
|
|
|
|
* are known to crash some Windows shells when pasted via clipboard.
|
|
|
|
*/
|
|
|
|
if (!ValidFileNameComponent(remote_name))
|
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "invalid file name component: %s", local_name);
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
return remote_name;
|
|
|
|
error:
|
|
|
|
free(remote_name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static char* concat_local_name(const char* dir, const char* file)
|
|
|
|
{
|
|
|
|
size_t len_dir = 0;
|
|
|
|
size_t len_file = 0;
|
|
|
|
char* buffer = NULL;
|
|
|
|
len_dir = strlen(dir);
|
|
|
|
len_file = strlen(file);
|
|
|
|
buffer = calloc(len_dir + 1 + len_file + 1, sizeof(char));
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!buffer)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
memcpy(buffer, dir, len_dir * sizeof(char));
|
|
|
|
buffer[len_dir] = '/';
|
|
|
|
memcpy(buffer + len_dir + 1, file, len_file * sizeof(char));
|
|
|
|
return buffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
static WCHAR* concat_remote_name(const WCHAR* dir, const WCHAR* file)
|
|
|
|
{
|
|
|
|
size_t len_dir = 0;
|
|
|
|
size_t len_file = 0;
|
|
|
|
WCHAR* buffer = NULL;
|
|
|
|
len_dir = _wcslen(dir);
|
|
|
|
len_file = _wcslen(file);
|
2019-04-03 11:17:51 +03:00
|
|
|
buffer = calloc(len_dir + 1 + len_file + 2, sizeof(WCHAR));
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!buffer)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
memcpy(buffer, dir, len_dir * sizeof(WCHAR));
|
|
|
|
buffer[len_dir] = L'\\';
|
|
|
|
memcpy(buffer + len_dir + 1, file, len_file * sizeof(WCHAR));
|
|
|
|
return buffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL add_file_to_list(const char* local_name, const WCHAR* remote_name, wArrayList* files);
|
|
|
|
|
|
|
|
static BOOL add_directory_entry_to_list(const char* local_dir_name, const WCHAR* remote_dir_name,
|
2017-11-14 15:57:00 +03:00
|
|
|
const struct dirent* entry, wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
BOOL result = FALSE;
|
|
|
|
char* local_name = NULL;
|
|
|
|
WCHAR* remote_name = NULL;
|
|
|
|
WCHAR* remote_base_name = NULL;
|
|
|
|
|
|
|
|
/* Skip special directory entries. */
|
|
|
|
if ((strcmp(entry->d_name, ".") == 0) || (strcmp(entry->d_name, "..") == 0))
|
|
|
|
return TRUE;
|
|
|
|
|
2017-04-09 02:29:52 +03:00
|
|
|
remote_base_name = convert_local_name_component_to_remote(entry->d_name);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:52 +03:00
|
|
|
if (!remote_base_name)
|
2017-04-09 02:29:51 +03:00
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
local_name = concat_local_name(local_dir_name, entry->d_name);
|
|
|
|
remote_name = concat_remote_name(remote_dir_name, remote_base_name);
|
|
|
|
|
|
|
|
if (local_name && remote_name)
|
|
|
|
result = add_file_to_list(local_name, remote_name, files);
|
|
|
|
|
|
|
|
free(remote_base_name);
|
|
|
|
free(remote_name);
|
|
|
|
free(local_name);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL do_add_directory_contents_to_list(const char* local_name, const WCHAR* remote_name,
|
2019-11-06 17:24:51 +03:00
|
|
|
DIR* dirp, wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For some reason POSIX does not require readdir() to be thread-safe.
|
|
|
|
* However, readdir_r() has really insane interface and is pretty bad
|
|
|
|
* replacement for it. Fortunately, most C libraries guarantee thread-
|
|
|
|
* safety of readdir() when it is used for distinct directory streams.
|
|
|
|
*
|
|
|
|
* Thus we can use readdir() in multithreaded applications if we are
|
|
|
|
* sure that it will not corrupt some global data. It would be nice
|
|
|
|
* to have a compile-time check for this here, but some C libraries
|
|
|
|
* do not provide a #define because of reasons (I'm looking at you,
|
|
|
|
* musl). We should not be breaking people's builds because of that,
|
|
|
|
* so we do nothing and proceed with fingers crossed.
|
|
|
|
*/
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
struct dirent* entry = NULL;
|
|
|
|
errno = 0;
|
|
|
|
entry = readdir(dirp);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!entry)
|
|
|
|
{
|
|
|
|
int err = errno;
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!err)
|
|
|
|
break;
|
|
|
|
|
|
|
|
WLog_ERR(TAG, "failed to read directory: %s", strerror(err));
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!add_directory_entry_to_list(local_name, remote_name, entry, files))
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL add_directory_contents_to_list(const char* local_name, const WCHAR* remote_name,
|
2019-11-06 17:24:51 +03:00
|
|
|
wArrayList* files)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
BOOL result = FALSE;
|
|
|
|
DIR* dirp = NULL;
|
2017-05-24 23:14:31 +03:00
|
|
|
WLog_VRB(TAG, "adding directory: %s", local_name);
|
2017-04-09 02:29:51 +03:00
|
|
|
dirp = opendir(local_name);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!dirp)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to open directory %s: %s", local_name, strerror(err));
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
result = do_add_directory_contents_to_list(local_name, remote_name, dirp, files);
|
|
|
|
|
|
|
|
if (closedir(dirp))
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_WARN(TAG, "failed to close directory: %s", strerror(err));
|
|
|
|
}
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
out:
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static BOOL add_file_to_list(const char* local_name, const WCHAR* remote_name, wArrayList* files)
|
|
|
|
{
|
|
|
|
struct posix_file* file = NULL;
|
2017-05-24 23:14:31 +03:00
|
|
|
WLog_VRB(TAG, "adding file: %s", local_name);
|
2017-04-09 02:29:51 +03:00
|
|
|
file = make_posix_file(local_name, remote_name);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!file)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
if (ArrayList_Add(files, file) < 0)
|
|
|
|
{
|
|
|
|
free_posix_file(file);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (file->is_directory)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This is effectively a recursive call, but we do not track
|
|
|
|
* recursion depth, thus filesystem loops can cause a crash.
|
|
|
|
*/
|
|
|
|
if (!add_directory_contents_to_list(local_name, remote_name, files))
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2017-07-03 20:57:41 +03:00
|
|
|
static const char* get_basename(const char* name)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
const char* c = name;
|
|
|
|
const char* last_name = name;
|
|
|
|
|
|
|
|
while (*c++)
|
|
|
|
{
|
|
|
|
if (*c == '/')
|
|
|
|
last_name = c + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return last_name;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static BOOL process_file_name(const char* local_name, wArrayList* files)
|
|
|
|
{
|
2017-04-09 02:29:51 +03:00
|
|
|
BOOL result = FALSE;
|
|
|
|
const char* base_name = NULL;
|
|
|
|
WCHAR* remote_name = NULL;
|
|
|
|
/*
|
|
|
|
* Start with the base name of the file. text/uri-list contains the
|
|
|
|
* exact files selected by the user, and we want the remote files
|
|
|
|
* to have names relative to that selection.
|
|
|
|
*/
|
2017-07-03 20:57:41 +03:00
|
|
|
base_name = get_basename(local_name);
|
2017-04-09 02:29:52 +03:00
|
|
|
remote_name = convert_local_name_component_to_remote(base_name);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:52 +03:00
|
|
|
if (!remote_name)
|
|
|
|
return FALSE;
|
2017-04-09 02:29:51 +03:00
|
|
|
|
|
|
|
result = add_file_to_list(local_name, remote_name, files);
|
|
|
|
free(remote_name);
|
|
|
|
return result;
|
2017-04-09 02:29:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL process_uri(const char* uri, size_t uri_len, wArrayList* files)
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
const char prefix[] = "file://";
|
2017-04-09 02:29:51 +03:00
|
|
|
BOOL result = FALSE;
|
|
|
|
char* name = NULL;
|
2019-04-05 14:17:28 +03:00
|
|
|
const size_t prefixLen = strnlen(prefix, sizeof(prefix));
|
2017-05-24 23:14:31 +03:00
|
|
|
WLog_VRB(TAG, "processing URI: %.*s", uri_len, uri);
|
2017-04-09 02:29:51 +03:00
|
|
|
|
2019-04-03 11:17:51 +03:00
|
|
|
if ((uri_len < prefixLen) || strncmp(uri, prefix, prefixLen))
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "non-'file://' URI schemes are not supported");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2019-04-03 11:17:51 +03:00
|
|
|
name = decode_percent_encoded_string(uri + prefixLen, uri_len - prefixLen);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!name)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
result = process_file_name(name, files);
|
|
|
|
out:
|
|
|
|
free(name);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
static BOOL process_uri_list(const char* data, size_t length, wArrayList* files)
|
|
|
|
{
|
2017-04-09 02:29:51 +03:00
|
|
|
const char* cur = data;
|
|
|
|
const char* lim = data + length;
|
|
|
|
const char* start = NULL;
|
|
|
|
const char* stop = NULL;
|
2017-05-24 23:14:31 +03:00
|
|
|
WLog_VRB(TAG, "processing URI list:\n%.*s", length, data);
|
2017-04-09 02:29:50 +03:00
|
|
|
ArrayList_Clear(files);
|
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 == '#');
|
|
|
|
start = cur;
|
|
|
|
|
|
|
|
for (stop = cur; stop < lim; stop++)
|
|
|
|
{
|
|
|
|
if (*stop == '\r')
|
|
|
|
{
|
|
|
|
if ((stop + 1 < lim) && (*(stop + 1) == '\n'))
|
|
|
|
cur = stop + 2;
|
|
|
|
else
|
|
|
|
cur = stop + 1;
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
break;
|
|
|
|
}
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (*stop == '\n')
|
|
|
|
{
|
|
|
|
cur = stop + 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (stop == lim)
|
|
|
|
cur = lim;
|
|
|
|
|
|
|
|
if (comment)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!process_uri(start, stop - start, files))
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
static BOOL convert_local_file_to_filedescriptor(const struct posix_file* file,
|
2019-11-06 17:24:51 +03:00
|
|
|
FILEDESCRIPTOR* descriptor)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
|
|
|
size_t remote_len = 0;
|
|
|
|
descriptor->dwFlags = FD_ATTRIBUTES | FD_FILESIZE | FD_SHOWPROGRESSUI;
|
|
|
|
|
|
|
|
if (file->is_directory)
|
|
|
|
{
|
|
|
|
descriptor->dwFileAttributes = FILE_ATTRIBUTE_DIRECTORY;
|
|
|
|
descriptor->nFileSizeLow = 0;
|
|
|
|
descriptor->nFileSizeHigh = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
descriptor->dwFileAttributes = FILE_ATTRIBUTE_NORMAL;
|
|
|
|
descriptor->nFileSizeLow = (file->size >> 0) & 0xFFFFFFFF;
|
|
|
|
descriptor->nFileSizeHigh = (file->size >> 32) & 0xFFFFFFFF;
|
|
|
|
}
|
|
|
|
|
|
|
|
remote_len = _wcslen(file->remote_name);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-21 14:13:52 +03:00
|
|
|
if (remote_len + 1 > ARRAYSIZE(descriptor->cFileName))
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
2019-11-06 17:24:51 +03: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;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
static FILEDESCRIPTOR* convert_local_file_list_to_filedescriptors(wArrayList* files)
|
|
|
|
{
|
2017-04-09 02:29:50 +03:00
|
|
|
int i;
|
|
|
|
int count = 0;
|
|
|
|
FILEDESCRIPTOR* descriptors = NULL;
|
|
|
|
count = ArrayList_Count(files);
|
|
|
|
descriptors = calloc(count, sizeof(descriptors[0]));
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!descriptors)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
{
|
|
|
|
const struct posix_file* file = ArrayList_GetItem(files, i);
|
|
|
|
|
|
|
|
if (!convert_local_file_to_filedescriptor(file, &descriptors[i]))
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
return descriptors;
|
|
|
|
error:
|
|
|
|
free(descriptors);
|
2017-04-09 02:29:50 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void* convert_uri_list_to_filedescriptors(wClipboard* clipboard, UINT32 formatId,
|
2019-11-06 17:24:51 +03:00
|
|
|
const void* data, UINT32* pSize)
|
2017-04-09 02:29:50 +03:00
|
|
|
{
|
|
|
|
FILEDESCRIPTOR* descriptors = NULL;
|
|
|
|
|
|
|
|
if (!clipboard || !data || !pSize)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (formatId != ClipboardGetFormatId(clipboard, "text/uri-list"))
|
|
|
|
return NULL;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
if (!process_uri_list((const char*)data, *pSize, clipboard->localFiles))
|
2017-04-09 02:29:50 +03:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
descriptors = convert_local_file_list_to_filedescriptors(clipboard->localFiles);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!descriptors)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
*pSize = ArrayList_Count(clipboard->localFiles) * sizeof(FILEDESCRIPTOR);
|
2017-04-09 02:29:51 +03:00
|
|
|
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
|
2017-04-09 02:29:50 +03:00
|
|
|
return descriptors;
|
|
|
|
}
|
|
|
|
|
2019-02-20 19:05:47 +03:00
|
|
|
static void* convert_filedescriptors_to_uri_list(wClipboard* clipboard, UINT32 formatId,
|
2019-11-06 17:24:51 +03:00
|
|
|
const void* data, UINT32* pSize)
|
2019-02-20 19:05:47 +03:00
|
|
|
{
|
|
|
|
const FILEDESCRIPTOR* descriptors;
|
2019-05-08 15:41:22 +03:00
|
|
|
UINT32 nrDescriptors = 0;
|
2019-02-20 19:05:47 +03:00
|
|
|
size_t count, x, alloc, pos, baseLength = 0;
|
2019-11-06 17:24:51 +03:00
|
|
|
const char* src = (const char*)data;
|
2019-02-20 19:05:47 +03:00
|
|
|
char* dst;
|
|
|
|
|
|
|
|
if (!clipboard || !data || !pSize)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (*pSize < sizeof(UINT32))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (clipboard->delegate.basePath)
|
|
|
|
baseLength = strnlen(clipboard->delegate.basePath, MAX_PATH);
|
|
|
|
|
|
|
|
if (baseLength < 1)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (clipboard->delegate.ClientRequestFileSize)
|
|
|
|
nrDescriptors = (UINT32)(src[3] << 24) | (UINT32)(src[2] << 16) | (UINT32)(src[1] << 8) |
|
|
|
|
(src[0] & 0xFF);
|
|
|
|
|
|
|
|
count = (*pSize - 4) / sizeof(FILEDESCRIPTOR);
|
|
|
|
|
|
|
|
if ((count < 1) || (count != nrDescriptors))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
descriptors = (const FILEDESCRIPTOR*)&src[4];
|
|
|
|
|
|
|
|
if (formatId != ClipboardGetFormatId(clipboard, "FileGroupDescriptorW"))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
alloc = 0;
|
|
|
|
|
|
|
|
/* Get total size of file names */
|
|
|
|
for (x = 0; x < count; x++)
|
|
|
|
alloc += _wcsnlen(descriptors[x].cFileName, ARRAYSIZE(descriptors[x].cFileName));
|
|
|
|
|
|
|
|
/* Append a prefix file:// and postfix \r\n for each file */
|
|
|
|
alloc += (sizeof("/\r\n") + baseLength) * count;
|
|
|
|
dst = calloc(alloc, sizeof(char));
|
|
|
|
|
|
|
|
if (!dst)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
pos = 0;
|
|
|
|
|
|
|
|
for (x = 0; x < count; x++)
|
|
|
|
{
|
2019-05-08 15:41:22 +03:00
|
|
|
int rc;
|
2019-02-20 19:05:47 +03:00
|
|
|
const FILEDESCRIPTOR* cur = &descriptors[x];
|
|
|
|
size_t curLen = _wcsnlen(cur->cFileName, ARRAYSIZE(cur->cFileName));
|
|
|
|
char* curName = NULL;
|
2019-05-08 15:41:22 +03:00
|
|
|
rc = ConvertFromUnicode(CP_UTF8, 0, cur->cFileName, (int)curLen, &curName, 0, NULL, NULL);
|
|
|
|
|
|
|
|
if (rc != (int)curLen)
|
|
|
|
{
|
|
|
|
free(curName);
|
|
|
|
free(dst);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = _snprintf(&dst[pos], alloc - pos, "%s/%s\r\n", clipboard->delegate.basePath, curName);
|
2019-02-20 19:05:47 +03:00
|
|
|
free(curName);
|
2019-05-08 15:41:22 +03:00
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
{
|
|
|
|
free(dst);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
pos += (size_t)rc;
|
2019-02-20 19:05:47 +03:00
|
|
|
}
|
|
|
|
|
2019-05-08 15:41:22 +03:00
|
|
|
*pSize = (UINT32)alloc;
|
2019-02-20 19:05:47 +03:00
|
|
|
clipboard->fileListSequenceNumber = clipboard->sequenceNumber;
|
|
|
|
return dst;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
static BOOL register_file_formats_and_synthesizers(wClipboard* clipboard)
|
|
|
|
{
|
|
|
|
UINT32 file_group_format_id;
|
|
|
|
UINT32 local_file_format_id;
|
|
|
|
file_group_format_id = ClipboardRegisterFormat(clipboard, "FileGroupDescriptorW");
|
|
|
|
local_file_format_id = ClipboardRegisterFormat(clipboard, "text/uri-list");
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!file_group_format_id || !local_file_format_id)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
clipboard->localFiles = ArrayList_New(FALSE);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
if (!clipboard->localFiles)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
ArrayList_Object(clipboard->localFiles)->fnObjectFree = free_posix_file;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, local_file_format_id, file_group_format_id,
|
2017-11-14 15:57:00 +03:00
|
|
|
convert_uri_list_to_filedescriptors))
|
2017-04-09 02:29:50 +03:00
|
|
|
goto error_free_local_files;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
if (!ClipboardRegisterSynthesizer(clipboard, file_group_format_id, local_file_format_id,
|
2019-02-20 19:05:47 +03:00
|
|
|
convert_filedescriptors_to_uri_list))
|
|
|
|
goto error_free_local_files;
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
return TRUE;
|
|
|
|
error_free_local_files:
|
|
|
|
ArrayList_Free(clipboard->localFiles);
|
|
|
|
clipboard->localFiles = NULL;
|
|
|
|
error:
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2017-08-11 11:07:46 +03:00
|
|
|
static UINT posix_file_get_size(const struct posix_file* file, INT64* size)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
struct stat statbuf;
|
|
|
|
|
|
|
|
if (stat(file->local_name, &statbuf) < 0)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to stat %s: %s", file->local_name, strerror(err));
|
|
|
|
return ERROR_FILE_INVALID;
|
|
|
|
}
|
|
|
|
|
|
|
|
*size = statbuf.st_size;
|
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT posix_file_request_size(wClipboardDelegate* delegate,
|
2017-11-14 15:57:00 +03:00
|
|
|
const wClipboardFileSizeRequest* request)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
UINT error = NO_ERROR;
|
2017-08-11 11:07:46 +03:00
|
|
|
INT64 size = 0;
|
2017-04-09 02:29:51 +03:00
|
|
|
struct posix_file* file = NULL;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
file = ArrayList_GetItem(delegate->clipboard->localFiles, request->listIndex);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
if (!file)
|
|
|
|
return ERROR_INDEX_ABSENT;
|
|
|
|
|
|
|
|
error = posix_file_get_size(file, &size);
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
error = delegate->ClipboardFileSizeFailure(delegate, request, error);
|
|
|
|
else
|
|
|
|
error = delegate->ClipboardFileSizeSuccess(delegate, request, size);
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
WLog_WARN(TAG, "failed to report file size result: 0x%08X", error);
|
|
|
|
|
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
static UINT posix_file_read_open(struct posix_file* file)
|
|
|
|
{
|
|
|
|
struct stat statbuf;
|
|
|
|
|
|
|
|
if (file->fd >= 0)
|
|
|
|
return NO_ERROR;
|
|
|
|
|
|
|
|
file->fd = open(file->local_name, O_RDONLY);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (file->fd < 0)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to open file %s: %s", file->local_name, strerror(err));
|
|
|
|
return ERROR_FILE_NOT_FOUND;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fstat(file->fd, &statbuf) < 0)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to stat file: %s", strerror(err));
|
|
|
|
return ERROR_FILE_INVALID;
|
|
|
|
}
|
|
|
|
|
|
|
|
file->offset = 0;
|
|
|
|
file->size = statbuf.st_size;
|
2017-05-24 23:14:31 +03:00
|
|
|
WLog_VRB(TAG, "open file %d -> %s", file->fd, file->local_name);
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_VRB(TAG, "file %d size: %" PRIu64 " bytes", file->fd, file->size);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT posix_file_read_seek(struct posix_file* file, UINT64 offset)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We should avoid seeking when possible as some filesystems (e.g.,
|
|
|
|
* an FTP server mapped via FUSE) may not support seeking. We keep
|
|
|
|
* an accurate account of the current file offset and do not call
|
|
|
|
* lseek() if the client requests file content sequentially.
|
|
|
|
*/
|
2019-02-07 16:34:37 +03:00
|
|
|
if (offset > INT64_MAX)
|
|
|
|
return ERROR_SEEK;
|
|
|
|
|
|
|
|
if (file->offset == (INT64)offset)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
return NO_ERROR;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_VRB(TAG, "file %d force seeking to %" PRIu64 ", current %" PRIu64, file->fd, offset,
|
|
|
|
file->offset);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
|
2019-02-07 16:34:37 +03:00
|
|
|
if (lseek(file->fd, (off_t)offset, SEEK_SET) < 0)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to seek file: %s", strerror(err));
|
|
|
|
return ERROR_SEEK;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
static UINT posix_file_read_perform(struct posix_file* file, 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
|
|
|
{
|
|
|
|
BYTE* buffer = NULL;
|
|
|
|
ssize_t amount = 0;
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_VRB(TAG, "file %d request read %" PRIu32 " bytes", file->fd, size);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
buffer = malloc(size);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (!buffer)
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "failed to allocate %" PRIu32 " buffer bytes", 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_ENOUGH_MEMORY;
|
|
|
|
}
|
|
|
|
|
|
|
|
amount = read(file->fd, buffer, size);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (amount < 0)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_ERR(TAG, "failed to read file: %s", strerror(err));
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
*actual_data = buffer;
|
|
|
|
*actual_size = amount;
|
|
|
|
file->offset += amount;
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_VRB(TAG, "file %d actual read %" PRIu32 " bytes (offset %" PRIu64 ")", file->fd, amount,
|
|
|
|
file->offset);
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
return NO_ERROR;
|
|
|
|
error:
|
|
|
|
free(buffer);
|
|
|
|
return ERROR_READ_FAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT posix_file_read_close(struct posix_file* file)
|
|
|
|
{
|
|
|
|
if (file->fd < 0)
|
|
|
|
return NO_ERROR;
|
|
|
|
|
|
|
|
if (file->offset == file->size)
|
|
|
|
{
|
2017-05-24 23:14:31 +03:00
|
|
|
WLog_VRB(TAG, "close file %d", file->fd);
|
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (close(file->fd) < 0)
|
|
|
|
{
|
|
|
|
int err = errno;
|
|
|
|
WLog_WARN(TAG, "failed to close fd %d: %s", file->fd, strerror(err));
|
|
|
|
}
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
file->fd = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT posix_file_get_range(struct posix_file* file, UINT64 offset, UINT32 size,
|
2017-11-14 15:57:00 +03:00
|
|
|
BYTE** actual_data, UINT32* actual_size)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
UINT error = NO_ERROR;
|
|
|
|
error = posix_file_read_open(file);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (error)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
error = posix_file_read_seek(file, offset);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (error)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
error = posix_file_read_perform(file, size, actual_data, actual_size);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (error)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
error = posix_file_read_close(file);
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (error)
|
|
|
|
goto out;
|
2017-11-14 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
out:
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT posix_file_request_range(wClipboardDelegate* delegate,
|
2017-11-14 15:57:00 +03:00
|
|
|
const wClipboardFileRangeRequest* request)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
UINT error = 0;
|
|
|
|
BYTE* data = NULL;
|
|
|
|
UINT32 size = 0;
|
|
|
|
UINT64 offset = 0;
|
|
|
|
struct posix_file* file = NULL;
|
|
|
|
|
|
|
|
if (!delegate || !delegate->clipboard || !request)
|
|
|
|
return ERROR_BAD_ARGUMENTS;
|
|
|
|
|
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 15:57:00 +03:00
|
|
|
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
if (!file)
|
|
|
|
return ERROR_INDEX_ABSENT;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
offset = (((UINT64)request->nPositionHigh) << 32) | ((UINT64)request->nPositionLow);
|
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
|
|
|
error = posix_file_get_range(file, offset, request->cbRequested, &data, &size);
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
error = delegate->ClipboardFileRangeFailure(delegate, request, error);
|
|
|
|
else
|
|
|
|
error = delegate->ClipboardFileRangeSuccess(delegate, request, data, size);
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
WLog_WARN(TAG, "failed to report file range result: 0x%08X", error);
|
|
|
|
|
|
|
|
free(data);
|
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
2017-11-14 15:57:00 +03:00
|
|
|
static UINT dummy_file_size_success(wClipboardDelegate* delegate,
|
|
|
|
const wClipboardFileSizeRequest* request, UINT64 fileSize)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
2017-11-14 15:57:00 +03:00
|
|
|
static UINT dummy_file_size_failure(wClipboardDelegate* delegate,
|
|
|
|
const wClipboardFileSizeRequest* request, UINT errorCode)
|
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
2017-11-14 15:57:00 +03:00
|
|
|
static UINT dummy_file_range_success(wClipboardDelegate* delegate,
|
2019-11-06 17:24:51 +03:00
|
|
|
const wClipboardFileRangeRequest* request, const BYTE* data,
|
|
|
|
UINT32 size)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
2017-11-14 15:57:00 +03:00
|
|
|
static UINT dummy_file_range_failure(wClipboardDelegate* delegate,
|
|
|
|
const wClipboardFileRangeRequest* request, UINT errorCode)
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
{
|
|
|
|
return ERROR_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:51 +03:00
|
|
|
static void setup_delegate(wClipboardDelegate* delegate)
|
|
|
|
{
|
|
|
|
delegate->ClientRequestFileSize = posix_file_request_size;
|
|
|
|
delegate->ClipboardFileSizeSuccess = dummy_file_size_success;
|
|
|
|
delegate->ClipboardFileSizeFailure = dummy_file_size_failure;
|
wClipboard/posix: implement file range retrieval
This is another bunch of callbacks which provide the file contents to
the clients. We jump through some extra hoops in order to have more
pleasant user experience.
Simple stuff goes first. The file offset (or position) is split into the
low and high parts because this is the format in which the clients
receive the request from the server. They can simply copy the values as
is into the struct without repackaging them (which we do instead in the
end to get a 64-bit off_t).
Another thing is that we try to minimize the number of lseek() calls and
to keep as few file descriptors open as possible. We cannot open all the
files at once as there could be thousands of them and we'll run out of
the allowed number of the fds. However, the server can (in theory)
request the file ranges randomly so we need to be prepared for that. One
way to do that would be to always open the file before reading and close
it immediately afterwards. A dead simple solution with an acceptable
performance, but... some file systems do not support seeking, such as
FTP directories mounted over FUSE. However, they handle sequential
reading just fine *and* the server requests the data sequentially most
of the time so we can exploit this.
Thus open the file only once, during the first range request and keep
it open until the server reads all the data. In order to know how much
data is left we keep an accurate account of all reads and maintain the
file offset ourselves. This also allows us to avoid calling lseek() when
the file offset will not be effectively changed. However, if the server
requests some weird offset then we have no choice and will attempt
seeking. Unfortunately, we cannot tell whether it is a genuine failure
or the file system just does not support seeking, so we do not handle
the error further. (One workaround would be to reopen the file and keep
reading it until we're at the correct offset.) In this way we can
support sequential-only file systems if the server requests the contents
sequentially (and it does).
Also note that we do an fstat() right after opening the file in order to
have an accurate value of file size, for this exact file descriptor we
will be using. We should have it filled it by now, but just in case...
There is one more thing to explain. The cbRequested field specifies the
maximum number of bytes the server can handle, not the required number.
Usually this is some power-of-two number like 64 KB, based on the size
of the files on the clipboard. This is why posix_file_read_perform()
does not attempt to fill the whole buffer by repeatedly calling read()
if it has read less data than requested. The server can handle underruns
just fine (and this spares us from special-casing the EOF condition).
2017-04-09 02:29:51 +03:00
|
|
|
delegate->ClientRequestFileRange = posix_file_request_range;
|
|
|
|
delegate->ClipboardFileRangeSuccess = dummy_file_range_success;
|
|
|
|
delegate->ClipboardFileRangeFailure = dummy_file_range_failure;
|
2017-04-09 02:29:51 +03:00
|
|
|
}
|
|
|
|
|
2017-04-09 02:29:50 +03:00
|
|
|
BOOL ClipboardInitPosixFileSubsystem(wClipboard* clipboard)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|