mirrors/FreeRDP
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
390762bff9
FreeRDP/client/common/client_cliprdr_file.c

2563 lines
71 KiB
C
Raw Normal View History

[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
/**
* FreeRDP: A Remote Desktop Protocol Implementation
* X11 Clipboard Redirection
*
* Copyright 2010-2011 Vic Lee
* Copyright 2015 Thincast Technologies GmbH
* Copyright 2015 DI (FH) Martin Haimberger <martin.haimberger@thincast.com>
* Copyright 2023 Armin Novak <armin.novak@thincast.com>
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
* Copyright 2023 Pascal Nowack <Pascal.Nowack@gmx.de>
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
*
* 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.
*/
#include <freerdp/config.h>
#include <stdlib.h>
#include <errno.h>
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#ifdef WITH_FUSE
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#define FUSE_USE_VERSION 30
#include <fuse_lowlevel.h>
#endif
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#include <sys/mount.h>
#include <sys/stat.h>
#include <errno.h>
#include <time.h>
#endif
#include <winpr/crt.h>
#include <winpr/assert.h>
#include <winpr/image.h>
#include <winpr/stream.h>
#include <winpr/clipboard.h>
#include <winpr/path.h>
#include <freerdp/utils/signal.h>
#include <freerdp/log.h>
#include <freerdp/client/cliprdr.h>
#include <freerdp/channels/channels.h>
#include <freerdp/channels/cliprdr.h>
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
#include <freerdp/client/client_cliprdr_file.h>
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
#define MAX_CLIP_DATA_DIR_LEN 10
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#define MAX_CLIPBOARD_FORMATS 255
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
#define NO_CLIP_DATA_ID (UINT64_C(1) << 32)
#define WIN32_FILETIME_TO_UNIX_EPOCH UINT64_C(11644473600)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#ifdef WITH_DEBUG_CLIPRDR
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
#define DEBUG_CLIPRDR(log, ...) WLog_Print(log, WLOG_DEBUG, __VA_ARGS__)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#else
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
#define DEBUG_CLIPRDR(log, ...) \
do \
{ \
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
} while (0)
#endif
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[warnings] fixed reserved-identifer warnings
2023-09-22 15:51:43 +03:00
typedef enum eFuseLowlevelOperationType
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
{
FUSE_LL_OPERATION_NONE,
FUSE_LL_OPERATION_LOOKUP,
FUSE_LL_OPERATION_GETATTR,
FUSE_LL_OPERATION_READ,
} FuseLowlevelOperationType;
[warnings] fixed reserved-identifer warnings
2023-09-22 15:51:43 +03:00
typedef struct sCliprdrFuseFile CliprdrFuseFile;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
[warnings] fixed reserved-identifer warnings
2023-09-22 15:51:43 +03:00
struct sCliprdrFuseFile
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
{
CliprdrFuseFile* parent;
wArrayList* children;
char* filename;
char* filename_with_root;
UINT32 list_idx;
fuse_ino_t ino;
BOOL is_directory;
BOOL is_readonly;
BOOL has_size;
UINT64 size;
BOOL has_last_write_time;
UINT64 last_write_time_unix;
BOOL has_clip_data_id;
UINT32 clip_data_id;
};
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
typedef struct
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context;
CliprdrFuseFile* clip_data_dir;
BOOL has_clip_data_id;
UINT32 clip_data_id;
} CliprdrFuseClipDataEntry;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
typedef struct
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context;
wArrayList* fuse_files;
BOOL all_files;
BOOL has_clip_data_id;
UINT32 clip_data_id;
} FuseFileClearContext;
typedef struct
{
FuseLowlevelOperationType operation_type;
CliprdrFuseFile* fuse_file;
fuse_req_t fuse_req;
UINT32 stream_id;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
} CliprdrFuseRequest;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
typedef struct
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* parent;
char* parent_path;
} CliprdrFuseFindParentContext;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
typedef struct
{
char* name;
FILE* fp;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
INT64 size;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
CliprdrFileContext* context;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
} CliprdrLocalFile;
typedef struct
{
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
UINT32 lockId;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
BOOL locked;
size_t count;
CliprdrLocalFile* files;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
CliprdrFileContext* context;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
} CliprdrLocalStream;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
struct cliprdr_file_context
{
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
/* FUSE related**/
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
HANDLE fuse_start_sync;
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
HANDLE fuse_stop_sync;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
HANDLE fuse_thread;
struct fuse_session* fuse_sess;
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
#if FUSE_USE_VERSION < 30
struct fuse_chan* ch;
#endif
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
wHashTable* inode_table;
wHashTable* clip_data_table;
wHashTable* request_table;
CliprdrFuseFile* root_dir;
CliprdrFuseClipDataEntry* clip_data_entry_without_id;
UINT32 current_clip_data_id;
fuse_ino_t next_ino;
UINT32 next_clip_data_id;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
UINT32 next_stream_id;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
/* File clipping */
BOOL file_formats_registered;
UINT32 file_capability_flags;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
UINT32 local_lock_id;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
wHashTable* local_streams;
wLog* log;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
void* clipboard;
CliprdrClientContext* context;
char* path;
[client,common] fixed winpr clipboard locking
2023-02-28 13:37:42 +03:00
char* exposed_path;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
BYTE server_data_hash[WINPR_SHA256_DIGEST_LENGTH];
BYTE client_data_hash[WINPR_SHA256_DIGEST_LENGTH];
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
};
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void fuse_file_free(void* data)
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* fuse_file = data;
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!fuse_file)
return;
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
ArrayList_Free(fuse_file->children);
free(fuse_file->filename_with_root);
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
free(fuse_file);
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static CliprdrFuseFile* fuse_file_new(void)
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_file = calloc(1, sizeof(CliprdrFuseFile));
if (!fuse_file)
return NULL;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_file->children = ArrayList_New(FALSE);
if (!fuse_file->children)
{
free(fuse_file);
return NULL;
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return fuse_file;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void clip_data_entry_free(void* data)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseClipDataEntry* clip_data_entry = data;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!clip_data_entry)
return;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (clip_data_entry->has_clip_data_id)
{
CliprdrFileContext* file_context = clip_data_entry->file_context;
CLIPRDR_UNLOCK_CLIPBOARD_DATA unlock_clipboard_data = { 0 };
WINPR_ASSERT(file_context);
unlock_clipboard_data.common.msgType = CB_UNLOCK_CLIPDATA;
unlock_clipboard_data.clipDataId = clip_data_entry->clip_data_id;
file_context->context->ClientUnlockClipboardData(file_context->context,
&unlock_clipboard_data);
clip_data_entry->has_clip_data_id = FALSE;
WLog_Print(file_context->log, WLOG_DEBUG, "Destroyed ClipDataEntry with id %u",
clip_data_entry->clip_data_id);
}
free(clip_data_entry);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL does_server_support_clipdata_locking(CliprdrFileContext* file_context)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (cliprdr_file_context_remote_get_flags(file_context) & CB_CAN_LOCK_CLIPDATA)
return TRUE;
return FALSE;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static UINT32 get_next_free_clip_data_id(CliprdrFileContext* file_context)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
UINT32 clip_data_id = 0;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
clip_data_id = file_context->next_clip_data_id;
while (clip_data_id == 0 ||
HashTable_GetItemValue(file_context->clip_data_table, (void*)(UINT_PTR)clip_data_id))
++clip_data_id;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
file_context->next_clip_data_id = clip_data_id + 1;
HashTable_Unlock(file_context->inode_table);
return clip_data_id;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static CliprdrFuseClipDataEntry* clip_data_entry_new(CliprdrFileContext* file_context,
BOOL needs_clip_data_id)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseClipDataEntry* clip_data_entry = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CLIPRDR_LOCK_CLIPBOARD_DATA lock_clipboard_data = { 0 };
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clip_data_entry = calloc(1, sizeof(CliprdrFuseClipDataEntry));
if (!clip_data_entry)
return NULL;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clip_data_entry->file_context = file_context;
clip_data_entry->clip_data_id = get_next_free_clip_data_id(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!needs_clip_data_id)
return clip_data_entry;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
lock_clipboard_data.common.msgType = CB_LOCK_CLIPDATA;
lock_clipboard_data.clipDataId = clip_data_entry->clip_data_id;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (file_context->context->ClientLockClipboardData(file_context->context, &lock_clipboard_data))
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
clip_data_entry_free(clip_data_entry);
HashTable_Unlock(file_context->inode_table);
return NULL;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clip_data_entry->has_clip_data_id = TRUE;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_DEBUG, "Created ClipDataEntry with id %u",
clip_data_entry->clip_data_id);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return clip_data_entry;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL should_remove_fuse_file(CliprdrFuseFile* fuse_file, BOOL all_files,
BOOL has_clip_data_id, BOOL clip_data_id)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (all_files)
return TRUE;
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (fuse_file->ino == FUSE_ROOT_ID)
return FALSE;
if (!fuse_file->has_clip_data_id && !has_clip_data_id)
return TRUE;
if (fuse_file->has_clip_data_id && has_clip_data_id && fuse_file->clip_data_id == clip_data_id)
return TRUE;
return FALSE;
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL maybe_clear_fuse_request(const void* key, void* value, void* arg)
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseRequest* fuse_request = value;
FuseFileClearContext* clear_context = arg;
CliprdrFileContext* file_context = clear_context->file_context;
CliprdrFuseFile* fuse_file = fuse_request->fuse_file;
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!should_remove_fuse_file(fuse_file, clear_context->all_files,
clear_context->has_clip_data_id, clear_context->clip_data_id))
return TRUE;
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Clearing FileContentsRequest for file \"%s\"",
fuse_file->filename_with_root);
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_reply_err(fuse_request->fuse_req, EIO);
HashTable_Remove(file_context->request_table, key);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL maybe_steal_inode(const void* key, void* value, void* arg)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* fuse_file = value;
FuseFileClearContext* clear_context = arg;
CliprdrFileContext* file_context = clear_context->file_context;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (should_remove_fuse_file(fuse_file, clear_context->all_files,
clear_context->has_clip_data_id, clear_context->clip_data_id))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!ArrayList_Append(clear_context->fuse_files, fuse_file))
WLog_Print(file_context->log, WLOG_ERROR,
"Failed to append FUSE file to list for deletion");
HashTable_Remove(file_context->inode_table, key);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL notify_delete_child(void* data, size_t index, va_list ap)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* child = data;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(child);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = va_arg(ap, CliprdrFileContext*);
CliprdrFuseFile* parent = va_arg(ap, CliprdrFuseFile*);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(parent);
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
WINPR_ASSERT(file_context->fuse_sess);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_lowlevel_notify_delete(file_context->fuse_sess, parent->ino, child->ino, child->filename,
strlen(child->filename));
return TRUE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL invalidate_inode(void* data, size_t index, va_list ap)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* fuse_file = data;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(fuse_file);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = va_arg(ap, CliprdrFileContext*);
WINPR_ASSERT(file_context);
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
WINPR_ASSERT(file_context->fuse_sess);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
ArrayList_ForEach(fuse_file->children, notify_delete_child, file_context, fuse_file);
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Invalidating inode %lu for file \"%s\"", fuse_file->ino,
fuse_file->filename);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_lowlevel_notify_inval_inode(file_context->fuse_sess, fuse_file->ino, 0, 0);
WLog_Print(file_context->log, WLOG_DEBUG, "Inode %lu invalidated", fuse_file->ino);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void clear_selection(CliprdrFileContext* file_context, BOOL all_selections,
CliprdrFuseClipDataEntry* clip_data_entry)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
FuseFileClearContext clear_context = { 0 };
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* root_dir = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* clip_data_dir = NULL;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
root_dir = file_context->root_dir;
WINPR_ASSERT(root_dir);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clear_context.file_context = file_context;
clear_context.fuse_files = ArrayList_New(FALSE);
WINPR_ASSERT(clear_context.fuse_files);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
wObject* aobj = ArrayList_Object(clear_context.fuse_files);
WINPR_ASSERT(aobj);
aobj->fnObjectFree = fuse_file_free;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (clip_data_entry)
{
clip_data_dir = clip_data_entry->clip_data_dir;
clip_data_entry->clip_data_dir = NULL;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(clip_data_dir);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
ArrayList_Remove(root_dir->children, clip_data_dir);
clear_context.has_clip_data_id = clip_data_dir->has_clip_data_id;
clear_context.clip_data_id = clip_data_dir->clip_data_id;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clear_context.all_files = all_selections;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (clip_data_entry && clip_data_entry->has_clip_data_id)
WLog_Print(file_context->log, WLOG_DEBUG, "Clearing selection for clipDataId %u",
clip_data_entry->clip_data_id);
else
WLog_Print(file_context->log, WLOG_DEBUG, "Clearing selection%s",
all_selections ? "s" : "");
HashTable_Foreach(file_context->request_table, maybe_clear_fuse_request, &clear_context);
HashTable_Foreach(file_context->inode_table, maybe_steal_inode, &clear_context);
HashTable_Unlock(file_context->inode_table);
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
if (file_context->fuse_sess)
{
/*
* fuse_lowlevel_notify_inval_inode() is a blocking operation. If we receive a
* FUSE request (e.g. read()), then FUSE would block in read(), since the
* mutex of the inode_table would still be locked, if we wouldn't unlock it
* here.
* So, to avoid a deadlock here, unlock the mutex and reply all incoming
* operations with -ENOENT until the invalidation process is complete.
*/
ArrayList_ForEach(clear_context.fuse_files, invalidate_inode, file_context);
if (clip_data_dir)
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
{
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
fuse_lowlevel_notify_delete(file_context->fuse_sess, file_context->root_dir->ino,
clip_data_dir->ino, clip_data_dir->filename,
strlen(clip_data_dir->filename));
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
}
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
ArrayList_Free(clear_context.fuse_files);
HashTable_Lock(file_context->inode_table);
if (clip_data_entry && clip_data_entry->has_clip_data_id)
WLog_Print(file_context->log, WLOG_DEBUG, "Selection cleared for clipDataId %u",
clip_data_entry->clip_data_id);
else
WLog_Print(file_context->log, WLOG_DEBUG, "Selection%s cleared", all_selections ? "s" : "");
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void clear_entry_selection(CliprdrFuseClipDataEntry* clip_data_entry)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(clip_data_entry);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!clip_data_entry->clip_data_dir)
return;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clear_selection(clip_data_entry->file_context, FALSE, clip_data_entry);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void clear_no_cdi_entry(CliprdrFileContext* file_context)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,cliprdr] use hash table for remote streams
2023-02-26 13:34:45 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context->inode_table);
HashTable_Lock(file_context->inode_table);
[coverity] 1543120 Check of thread-shared field evades lock acquisition
2024-04-15 12:47:53 +03:00
if (file_context->clip_data_entry_without_id)
{
clear_entry_selection(file_context->clip_data_entry_without_id);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
[coverity] 1543120 Check of thread-shared field evades lock acquisition
2024-04-15 12:47:53 +03:00
clip_data_entry_free(file_context->clip_data_entry_without_id);
file_context->clip_data_entry_without_id = NULL;
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
}
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL clear_clip_data_entries(const void* key, void* value, void* arg)
{
clear_entry_selection(value);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void clear_cdi_entries(CliprdrFileContext* file_context)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
HashTable_Foreach(file_context->clip_data_table, clear_clip_data_entries, NULL);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Clear(file_context->clip_data_table);
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
[build] fix Wmissing-prototypes
2023-08-01 09:12:57 +03:00
static UINT prepare_clip_data_entry_with_id(CliprdrFileContext* file_context)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseClipDataEntry* clip_data_entry = NULL;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clip_data_entry = clip_data_entry_new(file_context, TRUE);
if (!clip_data_entry)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_ERROR, "Failed to create clipDataEntry");
return ERROR_INTERNAL_ERROR;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
if (!HashTable_Insert(file_context->clip_data_table,
(void*)(UINT_PTR)clip_data_entry->clip_data_id, clip_data_entry))
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_ERROR, "Failed to insert clipDataEntry");
clip_data_entry_free(clip_data_entry);
[coverity] 1543263 Missing unlock
2024-04-11 14:27:16 +03:00
HashTable_Unlock(file_context->inode_table);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return ERROR_INTERNAL_ERROR;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
// HashTable_Insert owns clip_data_entry
// NOLINTNEXTLINE(clang-analyzer-unix.Malloc)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
file_context->current_clip_data_id = clip_data_entry->clip_data_id;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return CHANNEL_RC_OK;
}
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
[build] fix Wmissing-prototypes
2023-08-01 09:12:57 +03:00
static UINT prepare_clip_data_entry_without_id(CliprdrFileContext* file_context)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
{
WINPR_ASSERT(file_context);
WINPR_ASSERT(!file_context->clip_data_entry_without_id);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
file_context->clip_data_entry_without_id = clip_data_entry_new(file_context, FALSE);
if (!file_context->clip_data_entry_without_id)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_ERROR, "Failed to create clipDataEntry");
return ERROR_INTERNAL_ERROR;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return CHANNEL_RC_OK;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
#endif
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
UINT cliprdr_file_context_notify_new_server_format_list(CliprdrFileContext* file_context)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(file_context->context);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clear_no_cdi_entry(file_context);
/* TODO: assign timeouts to old locks instead */
clear_cdi_entries(file_context);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (does_server_support_clipdata_locking(file_context))
return prepare_clip_data_entry_with_id(file_context);
else
return prepare_clip_data_entry_without_id(file_context);
#else
return CHANNEL_RC_OK;
#endif
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
UINT cliprdr_file_context_notify_new_client_format_list(CliprdrFileContext* file_context)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(file_context->context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clear_no_cdi_entry(file_context);
/* TODO: assign timeouts to old locks instead */
clear_cdi_entries(file_context);
#endif
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return CHANNEL_RC_OK;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static CliprdrLocalStream* cliprdr_local_stream_new(CliprdrFileContext* context, UINT32 streamID,
const char* data, size_t size);
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
static void cliprdr_file_session_terminate(CliprdrFileContext* file, BOOL stop_thread);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL local_stream_discard(const void* key, void* value, void* arg);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void writelog(wLog* log, DWORD level, const char* fname, const char* fkt, size_t line, ...)
{
if (!WLog_IsLevelActive(log, level))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
return;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
va_list ap;
va_start(ap, line);
WLog_PrintMessageVA(log, WLOG_MESSAGE_TEXT, level, line, fname, fkt, ap);
va_end(ap);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_lookup(fuse_req_t req, fuse_ino_t parent, const char* name);
static void cliprdr_file_fuse_getattr(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info* fi);
static void cliprdr_file_fuse_readdir(fuse_req_t req, fuse_ino_t ino, size_t size, off_t off,
struct fuse_file_info* fi);
static void cliprdr_file_fuse_read(fuse_req_t req, fuse_ino_t ino, size_t size, off_t off,
struct fuse_file_info* fi);
static void cliprdr_file_fuse_open(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info* fi);
static void cliprdr_file_fuse_opendir(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info* fi);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static const struct fuse_lowlevel_ops cliprdr_file_fuse_oper = {
.lookup = cliprdr_file_fuse_lookup,
.getattr = cliprdr_file_fuse_getattr,
.readdir = cliprdr_file_fuse_readdir,
.open = cliprdr_file_fuse_open,
.read = cliprdr_file_fuse_read,
.opendir = cliprdr_file_fuse_opendir,
};
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static CliprdrFuseFile* get_fuse_file_by_ino(CliprdrFileContext* file_context, fuse_ino_t fuse_ino)
{
WINPR_ASSERT(file_context);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return HashTable_GetItemValue(file_context->inode_table, (void*)(UINT_PTR)fuse_ino);
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static CliprdrFuseFile* get_fuse_file_by_name_from_parent(CliprdrFileContext* file_context,
CliprdrFuseFile* parent, const char* name)
{
WINPR_ASSERT(file_context);
WINPR_ASSERT(parent);
for (size_t i = 0; i < ArrayList_Count(parent->children); ++i)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* child = ArrayList_GetItem(parent->children, i);
WINPR_ASSERT(child);
if (strcmp(name, child->filename) == 0)
return child;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Requested file \"%s\" in directory \"%s\" does not exist",
name, parent->filename);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return NULL;
}
static CliprdrFuseRequest* cliprdr_fuse_request_new(CliprdrFileContext* file_context,
CliprdrFuseFile* fuse_file, fuse_req_t fuse_req,
FuseLowlevelOperationType operation_type)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseRequest* fuse_request = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
UINT32 stream_id = file_context->next_stream_id;
WINPR_ASSERT(file_context);
WINPR_ASSERT(fuse_file);
fuse_request = calloc(1, sizeof(CliprdrFuseRequest));
if (!fuse_request)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_ERROR, "Failed to allocate FUSE request for file \"%s\"",
fuse_file->filename_with_root);
return NULL;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_request->fuse_file = fuse_file;
fuse_request->fuse_req = fuse_req;
fuse_request->operation_type = operation_type;
while (stream_id == 0 ||
HashTable_GetItemValue(file_context->request_table, (void*)(UINT_PTR)stream_id))
++stream_id;
fuse_request->stream_id = stream_id;
file_context->next_stream_id = stream_id + 1;
if (!HashTable_Insert(file_context->request_table, (void*)(UINT_PTR)fuse_request->stream_id,
fuse_request))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_ERROR, "Failed to track FUSE request for file \"%s\"",
fuse_file->filename_with_root);
free(fuse_request);
return NULL;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return fuse_request;
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static BOOL request_file_size_async(CliprdrFileContext* file_context, CliprdrFuseFile* fuse_file,
fuse_req_t fuse_req, FuseLowlevelOperationType operation_type)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseRequest* fuse_request = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CLIPRDR_FILE_CONTENTS_REQUEST file_contents_request = { 0 };
WINPR_ASSERT(file_context);
WINPR_ASSERT(fuse_file);
fuse_request = cliprdr_fuse_request_new(file_context, fuse_file, fuse_req, operation_type);
if (!fuse_request)
return FALSE;
file_contents_request.common.msgType = CB_FILECONTENTS_REQUEST;
file_contents_request.streamId = fuse_request->stream_id;
file_contents_request.listIndex = fuse_file->list_idx;
file_contents_request.dwFlags = FILECONTENTS_SIZE;
file_contents_request.cbRequested = 0x8;
file_contents_request.haveClipDataId = fuse_file->has_clip_data_id;
file_contents_request.clipDataId = fuse_file->clip_data_id;
if (file_context->context->ClientFileContentsRequest(file_context->context,
&file_contents_request))
{
WLog_Print(file_context->log, WLOG_ERROR,
"Failed to send FileContentsRequest for file \"%s\"",
fuse_file->filename_with_root);
HashTable_Remove(file_context->request_table, (void*)(UINT_PTR)fuse_request->stream_id);
return FALSE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Requested file size for file \"%s\" with stream id %u",
fuse_file->filename, fuse_request->stream_id);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void write_file_attributes(CliprdrFuseFile* fuse_file, struct stat* attr)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
memset(attr, 0, sizeof(struct stat));
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!fuse_file)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
return;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
attr->st_ino = fuse_file->ino;
if (fuse_file->is_directory)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
attr->st_mode = S_IFDIR | (fuse_file->is_readonly ? 0555 : 0755);
attr->st_nlink = 2;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
else
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
attr->st_mode = S_IFREG | (fuse_file->is_readonly ? 0444 : 0644);
attr->st_nlink = 1;
attr->st_size = fuse_file->size;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
attr->st_uid = getuid();
attr->st_gid = getgid();
attr->st_atime = attr->st_mtime = attr->st_ctime =
(fuse_file->has_last_write_time ? fuse_file->last_write_time_unix : time(NULL));
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_lookup(fuse_req_t fuse_req, fuse_ino_t parent_ino, const char* name)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = fuse_req_userdata(fuse_req);
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* parent = NULL;
CliprdrFuseFile* fuse_file = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
struct fuse_entry_param entry = { 0 };
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
HashTable_Lock(file_context->inode_table);
if (!(parent = get_fuse_file_by_ino(file_context, parent_ino)) || !parent->is_directory)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
}
if (!(fuse_file = get_fuse_file_by_name_from_parent(file_context, parent, name)))
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
}
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "lookup() has been called for \"%s\"", name);
DEBUG_CLIPRDR(file_context->log, "Parent is \"%s\", child is \"%s\"",
parent->filename_with_root, fuse_file->filename_with_root);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!fuse_file->is_directory && !fuse_file->has_size)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
BOOL result = 0;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
result =
request_file_size_async(file_context, fuse_file, fuse_req, FUSE_LL_OPERATION_LOOKUP);
HashTable_Unlock(file_context->inode_table);
if (!result)
fuse_reply_err(fuse_req, EIO);
return;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
entry.ino = fuse_file->ino;
write_file_attributes(fuse_file, &entry.attr);
entry.attr_timeout = 1.0;
entry.entry_timeout = 1.0;
HashTable_Unlock(file_context->inode_table);
fuse_reply_entry(fuse_req, &entry);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_getattr(fuse_req_t fuse_req, fuse_ino_t fuse_ino,
struct fuse_file_info* file_info)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = fuse_req_userdata(fuse_req);
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
struct stat attr = { 0 };
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
if (!(fuse_file = get_fuse_file_by_ino(file_context, fuse_ino)))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "getattr() has been called for file \"%s\"",
fuse_file->filename_with_root);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!fuse_file->is_directory && !fuse_file->has_size)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
BOOL result = 0;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
result =
request_file_size_async(file_context, fuse_file, fuse_req, FUSE_LL_OPERATION_GETATTR);
HashTable_Unlock(file_context->inode_table);
if (!result)
fuse_reply_err(fuse_req, EIO);
return;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
write_file_attributes(fuse_file, &attr);
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_reply_attr(fuse_req, &attr, 1.0);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_open(fuse_req_t fuse_req, fuse_ino_t fuse_ino,
struct fuse_file_info* file_info)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = fuse_req_userdata(fuse_req);
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
if (!(fuse_file = get_fuse_file_by_ino(file_context, fuse_ino)))
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
}
if (fuse_file->is_directory)
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, EISDIR);
return;
}
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if ((file_info->flags & O_ACCMODE) != O_RDONLY)
{
fuse_reply_err(fuse_req, EACCES);
return;
}
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
/* Important for KDE to get file correctly */
file_info->direct_io = 1;
[client,common] fixed winpr clipboard locking
2023-02-28 13:37:42 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_reply_open(fuse_req, file_info);
}
static BOOL request_file_range_async(CliprdrFileContext* file_context, CliprdrFuseFile* fuse_file,
fuse_req_t fuse_req, off_t offset, size_t requested_size)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseRequest* fuse_request = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CLIPRDR_FILE_CONTENTS_REQUEST file_contents_request = { 0 };
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(fuse_file);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_request =
cliprdr_fuse_request_new(file_context, fuse_file, fuse_req, FUSE_LL_OPERATION_READ);
if (!fuse_request)
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
return FALSE;
[client,common] fixed winpr clipboard locking
2023-02-28 13:37:42 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
file_contents_request.common.msgType = CB_FILECONTENTS_REQUEST;
file_contents_request.streamId = fuse_request->stream_id;
file_contents_request.listIndex = fuse_file->list_idx;
file_contents_request.dwFlags = FILECONTENTS_RANGE;
file_contents_request.nPositionLow = offset & 0xFFFFFFFF;
file_contents_request.nPositionHigh = offset >> 32 & 0xFFFFFFFF;
file_contents_request.cbRequested = requested_size;
file_contents_request.haveClipDataId = fuse_file->has_clip_data_id;
file_contents_request.clipDataId = fuse_file->clip_data_id;
if (file_context->context->ClientFileContentsRequest(file_context->context,
&file_contents_request))
{
WLog_Print(file_context->log, WLOG_ERROR,
"Failed to send FileContentsRequest for file \"%s\"",
fuse_file->filename_with_root);
HashTable_Remove(file_context->request_table, (void*)(UINT_PTR)fuse_request->stream_id);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
return FALSE;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
}
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
// file_context->request_table owns fuse_request
// NOLINTBEGIN(clang-analyzer-unix.Malloc)
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(
file_context->log,
"Requested file range (%zu Bytes at offset %lu) for file \"%s\" with stream id %u",
requested_size, offset, fuse_file->filename, fuse_request->stream_id);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
// NOLINTEND(clang-analyzer-unix.Malloc)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_read(fuse_req_t fuse_req, fuse_ino_t fuse_ino, size_t size,
off_t offset, struct fuse_file_info* file_info)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = fuse_req_userdata(fuse_req);
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
BOOL result = 0;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
if (!(fuse_file = get_fuse_file_by_ino(file_context, fuse_ino)))
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
}
if (fuse_file->is_directory)
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, EISDIR);
return;
}
if (!fuse_file->has_size || offset > fuse_file->size)
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, EINVAL);
return;
}
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
size = MIN(size, 8 * 1024 * 1024);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
result = request_file_range_async(file_context, fuse_file, fuse_req, offset, size);
HashTable_Unlock(file_context->inode_table);
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!result)
fuse_reply_err(fuse_req, EIO);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_opendir(fuse_req_t fuse_req, fuse_ino_t fuse_ino,
struct fuse_file_info* file_info)
{
CliprdrFileContext* file_context = fuse_req_userdata(fuse_req);
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
HashTable_Lock(file_context->inode_table);
if (!(fuse_file = get_fuse_file_by_ino(file_context, fuse_ino)))
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
}
if (!fuse_file->is_directory)
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOTDIR);
return;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if ((file_info->flags & O_ACCMODE) != O_RDONLY)
{
fuse_reply_err(fuse_req, EACCES);
return;
}
fuse_reply_open(fuse_req, file_info);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void cliprdr_file_fuse_readdir(fuse_req_t fuse_req, fuse_ino_t fuse_ino, size_t max_size,
off_t offset, struct fuse_file_info* file_info)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file_context = fuse_req_userdata(fuse_req);
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
CliprdrFuseFile* child = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
struct stat attr = { 0 };
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
size_t written_size = 0;
size_t entry_size = 0;
char* filename = NULL;
char* buf = NULL;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
if (!(fuse_file = get_fuse_file_by_ino(file_context, fuse_ino)))
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOENT);
return;
}
if (!fuse_file->is_directory)
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOTDIR);
return;
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Reading directory \"%s\" at offset %lu",
fuse_file->filename_with_root, offset);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (offset >= ArrayList_Count(fuse_file->children))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
fuse_reply_buf(fuse_req, NULL, 0);
return;
}
buf = calloc(max_size, sizeof(char));
if (!buf)
{
HashTable_Unlock(file_context->inode_table);
fuse_reply_err(fuse_req, ENOMEM);
return;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
written_size = 0;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
[tidy] move loop variable declaration to loop
2024-01-30 12:25:38 +03:00
for (off_t i = offset; i < 2; ++i)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (i == 0)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
write_file_attributes(fuse_file, &attr);
filename = ".";
}
else if (i == 1)
{
write_file_attributes(fuse_file->parent, &attr);
attr.st_ino = fuse_file->parent ? attr.st_ino : FUSE_ROOT_ID;
attr.st_mode = fuse_file->parent ? attr.st_mode : 0555;
filename = "..";
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
else
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
{
WINPR_ASSERT(FALSE);
}
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
/**
* buf needs to be large enough to hold the entry. If it's not, then the
* entry is not filled in but the size of the entry is still returned.
*/
entry_size = fuse_add_direntry(fuse_req, buf + written_size, max_size - written_size,
filename, &attr, i + 1);
if (entry_size > max_size - written_size)
break;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
written_size += entry_size;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
[tidy] move loop variable declaration to loop
2024-01-30 12:25:38 +03:00
for (size_t j = 0, i = 2; j < ArrayList_Count(fuse_file->children); ++j, ++i)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (i < offset)
continue;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
child = ArrayList_GetItem(fuse_file->children, j);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
write_file_attributes(child, &attr);
entry_size = fuse_add_direntry(fuse_req, buf + written_size, max_size - written_size,
child->filename, &attr, i + 1);
if (entry_size > max_size - written_size)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
break;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
written_size += entry_size;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
fuse_reply_buf(fuse_req, buf, written_size);
free(buf);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void fuse_abort(int sig, const char* signame, void* context)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file = (CliprdrFileContext*)context;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (file)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file->log, WLOG_INFO, "signal %s [%d] aborting session", signame, sig);
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
cliprdr_file_session_terminate(file, FALSE);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static DWORD WINAPI cliprdr_file_fuse_thread(LPVOID arg)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFileContext* file = (CliprdrFileContext*)arg;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
WINPR_ASSERT(file);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
DEBUG_CLIPRDR(file->log, "Starting fuse with mountpoint '%s'", file->path);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
struct fuse_args args = FUSE_ARGS_INIT(0, NULL);
fuse_opt_add_arg(&args, file->path);
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
file->fuse_sess = fuse_session_new(&args, &cliprdr_file_fuse_oper,
sizeof(cliprdr_file_fuse_oper), (void*)file);
SetEvent(file->fuse_start_sync);
if (file->fuse_sess != NULL)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
freerdp_add_signal_cleanup_handler(file, fuse_abort);
if (0 == fuse_session_mount(file->fuse_sess, file->path))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_session_loop(file->fuse_sess);
fuse_session_unmount(file->fuse_sess);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
freerdp_del_signal_cleanup_handler(file, fuse_abort);
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
WLog_Print(file->log, WLOG_DEBUG, "Waiting for FUSE stop sync");
if (WaitForSingleObject(file->fuse_stop_sync, INFINITE) == WAIT_FAILED)
WLog_Print(file->log, WLOG_ERROR, "Failed to wait for stop sync");
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_session_destroy(file->fuse_sess);
}
fuse_opt_free_args(&args);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
DEBUG_CLIPRDR(file->log, "Quitting fuse with mountpoint '%s'", file->path);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
ExitThread(0);
return 0;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static UINT cliprdr_file_context_server_file_contents_response(
CliprdrClientContext* cliprdr_context,
const CLIPRDR_FILE_CONTENTS_RESPONSE* file_contents_response)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFileContext* file_context = NULL;
CliprdrFuseRequest* fuse_request = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
struct fuse_entry_param entry = { 0 };
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(cliprdr_context);
WINPR_ASSERT(file_contents_response);
file_context = cliprdr_context->custom;
WINPR_ASSERT(file_context);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
fuse_request = HashTable_GetItemValue(file_context->request_table,
(void*)(UINT_PTR)file_contents_response->streamId);
if (!fuse_request)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Unlock(file_context->inode_table);
return CHANNEL_RC_OK;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (!(file_contents_response->common.msgFlags & CB_RESPONSE_OK))
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_WARN,
"FileContentsRequests for file \"%s\" was unsuccessful",
fuse_request->fuse_file->filename);
fuse_reply_err(fuse_request->fuse_req, EIO);
[cliprdr,common] fix file_context->request_table
2024-04-15 12:41:23 +03:00
HashTable_Remove(file_context->request_table,
(void*)(UINT_PTR)file_contents_response->streamId);
HashTable_Unlock(file_context->inode_table);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return CHANNEL_RC_OK;
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if ((fuse_request->operation_type == FUSE_LL_OPERATION_LOOKUP ||
fuse_request->operation_type == FUSE_LL_OPERATION_GETATTR) &&
client/cliprdr_file: Tighten up data size check for FILE_SIZE requests FILECONTENTS_SIZE requests explicitly specify the size of 8 Bytes, so expect that there are no further fill Bytes used.
2023-07-25 11:49:48 +03:00
file_contents_response->cbRequested != sizeof(UINT64))
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WLog_Print(file_context->log, WLOG_WARN,
"Received invalid file size for file \"%s\" from the client",
fuse_request->fuse_file->filename);
fuse_reply_err(fuse_request->fuse_req, EIO);
[cliprdr,common] fix file_context->request_table
2024-04-15 12:41:23 +03:00
HashTable_Remove(file_context->request_table,
(void*)(UINT_PTR)file_contents_response->streamId);
HashTable_Unlock(file_context->inode_table);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return CHANNEL_RC_OK;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (fuse_request->operation_type == FUSE_LL_OPERATION_LOOKUP ||
fuse_request->operation_type == FUSE_LL_OPERATION_GETATTR)
{
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Received file size for file \"%s\" with stream id %u",
fuse_request->fuse_file->filename, file_contents_response->streamId);
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
[warnings] fix -Wcast-qual
2023-11-24 11:17:24 +03:00
fuse_request->fuse_file->size = *((const UINT64*)file_contents_response->requestedData);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_request->fuse_file->has_size = TRUE;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
entry.ino = fuse_request->fuse_file->ino;
write_file_attributes(fuse_request->fuse_file, &entry.attr);
entry.attr_timeout = 1.0;
entry.entry_timeout = 1.0;
}
else if (fuse_request->operation_type == FUSE_LL_OPERATION_READ)
{
client/cliprdr_file: Move some debug messages under DEBUG_CLIPRDR Do no expose filenames of copied files, unless it is explicitly wanted.
2023-07-25 08:34:01 +03:00
DEBUG_CLIPRDR(file_context->log, "Received file range for file \"%s\" with stream id %u",
fuse_request->fuse_file->filename, file_contents_response->streamId);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
}
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
switch (fuse_request->operation_type)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
case FUSE_LL_OPERATION_NONE:
break;
case FUSE_LL_OPERATION_LOOKUP:
fuse_reply_entry(fuse_request->fuse_req, &entry);
break;
case FUSE_LL_OPERATION_GETATTR:
fuse_reply_attr(fuse_request->fuse_req, &entry.attr, entry.attr_timeout);
break;
case FUSE_LL_OPERATION_READ:
fuse_reply_buf(fuse_request->fuse_req,
(const char*)file_contents_response->requestedData,
file_contents_response->cbRequested);
break;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
[cliprdr,common] fix file_context->request_table
2024-04-15 12:41:23 +03:00
HashTable_Remove(file_context->request_table,
(void*)(UINT_PTR)file_contents_response->streamId);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return CHANNEL_RC_OK;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
static UINT cliprdr_file_context_send_file_contents_failure(
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
CliprdrFileContext* file, const CLIPRDR_FILE_CONTENTS_REQUEST* fileContentsRequest)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
{
CLIPRDR_FILE_CONTENTS_RESPONSE response = { 0 };
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
WINPR_ASSERT(file);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
WINPR_ASSERT(fileContentsRequest);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
const UINT64 offset = (((UINT64)fileContentsRequest->nPositionHigh) << 32) |
((UINT64)fileContentsRequest->nPositionLow);
[standard] replace __FUNCTION__ with __func__
2023-07-27 10:02:03 +03:00
writelog(file->log, WLOG_WARN, __FILE__, __func__, __LINE__,
[client,common] fix function name clash log is an intrinsic function on windows, rename to writelog
2023-03-06 15:43:00 +03:00
"server file contents request [lockID %" PRIu32 ", streamID %" PRIu32
", index %" PRIu32 "] offset %" PRIu64 ", size %" PRIu32 " failed",
fileContentsRequest->clipDataId, fileContentsRequest->streamId,
fileContentsRequest->listIndex, offset, fileContentsRequest->cbRequested);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
response.common.msgFlags = CB_RESPONSE_FAIL;
response.streamId = fileContentsRequest->streamId;
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
WINPR_ASSERT(file->context);
WINPR_ASSERT(file->context->ClientFileContentsResponse);
return file->context->ClientFileContentsResponse(file->context, &response);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
static UINT
cliprdr_file_context_send_contents_response(CliprdrFileContext* file,
const CLIPRDR_FILE_CONTENTS_REQUEST* request,
const void* data, size_t size)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
{
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
CLIPRDR_FILE_CONTENTS_RESPONSE response = { .streamId = request->streamId,
.requestedData = data,
.cbRequested = size,
.common.msgFlags = CB_RESPONSE_OK };
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
WINPR_ASSERT(request);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WINPR_ASSERT(file);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WLog_Print(file->log, WLOG_DEBUG, "send contents response streamID=%" PRIu32 ", size=%" PRIu32,
response.streamId, response.cbRequested);
WINPR_ASSERT(file->context);
WINPR_ASSERT(file->context->ClientFileContentsResponse);
return file->context->ClientFileContentsResponse(file->context, &response);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
static BOOL dump_streams(const void* key, void* value, void* arg)
{
const UINT32* ukey = key;
CliprdrLocalStream* cur = value;
[standard] replace __FUNCTION__ with __func__
2023-07-27 10:02:03 +03:00
writelog(cur->context->log, WLOG_WARN, __FILE__, __func__, __LINE__,
[client,common] fix function name clash log is an intrinsic function on windows, rename to writelog
2023-03-06 15:43:00 +03:00
"[key %" PRIu32 "] lockID %" PRIu32 ", count %" PRIuz ", locked %d", *ukey,
cur->lockId, cur->count, cur->locked);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
for (size_t x = 0; x < cur->count; x++)
{
const CliprdrLocalFile* file = &cur->files[x];
[standard] replace __FUNCTION__ with __func__
2023-07-27 10:02:03 +03:00
writelog(cur->context->log, WLOG_WARN, __FILE__, __func__, __LINE__, "file [%" PRIuz "] ",
x, file->name, file->size);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
}
[client,common] fix missing return
2023-03-05 19:07:46 +03:00
return TRUE;
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
static CliprdrLocalFile* file_info_for_request(CliprdrFileContext* file, UINT32 lockId,
UINT32 listIndex)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
{
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
WINPR_ASSERT(file);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
CliprdrLocalStream* cur = HashTable_GetItemValue(file->local_streams, &lockId);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (cur)
{
if (listIndex < cur->count)
{
CliprdrLocalFile* f = &cur->files[listIndex];
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
return f;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
else
{
[standard] replace __FUNCTION__ with __func__
2023-07-27 10:02:03 +03:00
writelog(file->log, WLOG_WARN, __FILE__, __func__, __LINE__,
[client,common] fix function name clash log is an intrinsic function on windows, rename to writelog
2023-03-06 15:43:00 +03:00
"invalid entry index for lockID %" PRIu32 ", index %" PRIu32 " [count %" PRIu32
"] [locked %d]",
lockId, listIndex, cur->count, cur->locked);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
else
{
[standard] replace __FUNCTION__ with __func__
2023-07-27 10:02:03 +03:00
writelog(file->log, WLOG_WARN, __FILE__, __func__, __LINE__,
[client,common] fix function name clash log is an intrinsic function on windows, rename to writelog
2023-03-06 15:43:00 +03:00
"missing entry for lockID %" PRIu32 ", index %" PRIu32, lockId, listIndex);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
HashTable_Foreach(file->local_streams, dump_streams, file);
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
return NULL;
}
static CliprdrLocalFile* file_for_request(CliprdrFileContext* file, UINT32 lockId, UINT32 listIndex)
{
CliprdrLocalFile* f = file_info_for_request(file, lockId, listIndex);
if (f)
{
if (!f->fp)
{
const char* name = f->name;
f->fp = winpr_fopen(name, "rb");
}
if (!f->fp)
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
{
[winpr] use winpr_strerror instead of strerror use the wrapper from WinPR to use the best implementation available.
2024-02-05 15:01:08 +03:00
char ebuffer[256] = { 0 };
[standard] replace __FUNCTION__ with __func__
2023-07-27 10:02:03 +03:00
writelog(file->log, WLOG_WARN, __FILE__, __func__, __LINE__,
[client,common] fix function name clash log is an intrinsic function on windows, rename to writelog
2023-03-06 15:43:00 +03:00
"[lockID %" PRIu32 ", index %" PRIu32
"] failed to open file '%s' [size %" PRId64 "] %s [%d]",
[winpr] use winpr_strerror instead of strerror use the wrapper from WinPR to use the best implementation available.
2024-02-05 15:01:08 +03:00
lockId, listIndex, f->name, f->size,
winpr_strerror(errno, ebuffer, sizeof(ebuffer)), errno);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
return NULL;
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
return f;
}
static void cliprdr_local_file_try_close(CliprdrLocalFile* file, UINT res, UINT64 offset,
UINT64 size)
{
WINPR_ASSERT(file);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
if (res != 0)
{
WINPR_ASSERT(file->context);
WLog_Print(file->context->log, WLOG_DEBUG, "closing file %s after error %" PRIu32,
file->name, res);
}
[client,common] fixed sign warnings
2023-07-27 21:36:38 +03:00
else if (((file->size > 0) && (offset + size >= (UINT64)file->size)))
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
{
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WINPR_ASSERT(file->context);
WLog_Print(file->context->log, WLOG_DEBUG, "closing file %s after read", file->name);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
}
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
else
{
// TODO: we need to keep track of open files to avoid running out of file descriptors
// TODO: for the time being just close again.
[fclose] ensure no invalid pointers are passed. fclose has undefined behaviour for NULL pointers, so check for these.
2023-04-27 10:23:51 +03:00
}
if (file->fp)
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
fclose(file->fp);
[client,common] fix value present flag check need to check for COMMAND_LINE_VALUE_PRESENT instad of COMMAND_LINE_ARGUMENT_PRESENT
2023-04-27 10:46:17 +03:00
file->fp = NULL;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
static UINT cliprdr_file_context_server_file_size_request(
CliprdrFileContext* file, const CLIPRDR_FILE_CONTENTS_REQUEST* fileContentsRequest)
{
WINPR_ASSERT(fileContentsRequest);
if (fileContentsRequest->cbRequested != sizeof(UINT64))
{
WLog_Print(file->log, WLOG_WARN, "unexpected FILECONTENTS_SIZE request: %" PRIu32 " bytes",
fileContentsRequest->cbRequested);
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
HashTable_Lock(file->local_streams);
UINT res = CHANNEL_RC_OK;
CliprdrLocalFile* rfile =
file_for_request(file, fileContentsRequest->clipDataId, fileContentsRequest->listIndex);
if (!rfile)
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
res = cliprdr_file_context_send_file_contents_failure(file, fileContentsRequest);
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
else
{
if (_fseeki64(rfile->fp, 0, SEEK_END) < 0)
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
res = cliprdr_file_context_send_file_contents_failure(file, fileContentsRequest);
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
else
{
const INT64 size = _ftelli64(rfile->fp);
rfile->size = size;
cliprdr_local_file_try_close(rfile, res, 0, 0);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
res = cliprdr_file_context_send_contents_response(file, fileContentsRequest, &size,
sizeof(size));
}
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
HashTable_Unlock(file->local_streams);
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
return res;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
static UINT cliprdr_file_context_server_file_range_request(
CliprdrFileContext* file, const CLIPRDR_FILE_CONTENTS_REQUEST* fileContentsRequest)
{
BYTE* data = NULL;
WINPR_ASSERT(fileContentsRequest);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
HashTable_Lock(file->local_streams);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
const UINT64 offset = (((UINT64)fileContentsRequest->nPositionHigh) << 32) |
((UINT64)fileContentsRequest->nPositionLow);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
CliprdrLocalFile* rfile =
file_for_request(file, fileContentsRequest->clipDataId, fileContentsRequest->listIndex);
if (!rfile)
goto fail;
if (_fseeki64(rfile->fp, offset, SEEK_SET) < 0)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
goto fail;
data = malloc(fileContentsRequest->cbRequested);
if (!data)
goto fail;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
const size_t r = fread(data, 1, fileContentsRequest->cbRequested, rfile->fp);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
const UINT rc = cliprdr_file_context_send_contents_response(file, fileContentsRequest, data, r);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
free(data);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
cliprdr_local_file_try_close(rfile, rc, offset, fileContentsRequest->cbRequested);
HashTable_Unlock(file->local_streams);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
return rc;
fail:
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
if (rfile)
cliprdr_local_file_try_close(rfile, ERROR_INTERNAL_ERROR, offset,
fileContentsRequest->cbRequested);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
free(data);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
HashTable_Unlock(file->local_streams);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
return cliprdr_file_context_send_file_contents_failure(file, fileContentsRequest);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
[casts] remove fnObject* function pointer casts use proper types that match the function pointer definition to avoid surprises if the code should be refactored
2023-09-20 16:57:39 +03:00
static void cliprdr_local_stream_free(void* obj);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
static UINT change_lock(CliprdrFileContext* file, UINT32 lockId, BOOL lock)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
{
[client,common] fix #9411 leak in file clipboard
2023-09-20 16:39:17 +03:00
UINT rc = CHANNEL_RC_OK;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
WINPR_ASSERT(file);
HashTable_Lock(file->local_streams);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
CliprdrLocalStream* stream = HashTable_GetItemValue(file->local_streams, &lockId);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (lock && !stream)
{
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
stream = cliprdr_local_stream_new(file, lockId, NULL, 0);
[client,common] fix #9411 leak in file clipboard
2023-09-20 16:39:17 +03:00
if (!HashTable_Insert(file->local_streams, &lockId, stream))
{
rc = ERROR_INTERNAL_ERROR;
cliprdr_local_stream_free(stream);
stream = NULL;
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
file->local_lock_id = lockId;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
if (stream)
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
{
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
stream->locked = lock;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
stream->lockId = lockId;
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (!lock)
[client,common] fix #9411 leak in file clipboard
2023-09-20 16:39:17 +03:00
{
if (!HashTable_Foreach(file->local_streams, local_stream_discard, file))
rc = ERROR_INTERNAL_ERROR;
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
HashTable_Unlock(file->local_streams);
[client,common] fix #9411 leak in file clipboard
2023-09-20 16:39:17 +03:00
return rc;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
static UINT cliprdr_file_context_lock(CliprdrClientContext* context,
const CLIPRDR_LOCK_CLIPBOARD_DATA* lockClipboardData)
{
WINPR_ASSERT(context);
WINPR_ASSERT(lockClipboardData);
CliprdrFileContext* file = (context->custom);
return change_lock(file, lockClipboardData->clipDataId, TRUE);
}
static UINT cliprdr_file_context_unlock(CliprdrClientContext* context,
const CLIPRDR_UNLOCK_CLIPBOARD_DATA* unlockClipboardData)
{
WINPR_ASSERT(context);
WINPR_ASSERT(unlockClipboardData);
CliprdrFileContext* file = (context->custom);
return change_lock(file, unlockClipboardData->clipDataId, FALSE);
}
static UINT cliprdr_file_context_server_file_contents_request(
CliprdrClientContext* context, const CLIPRDR_FILE_CONTENTS_REQUEST* fileContentsRequest)
{
UINT error = NO_ERROR;
WINPR_ASSERT(context);
WINPR_ASSERT(fileContentsRequest);
CliprdrFileContext* file = (context->custom);
WINPR_ASSERT(file);
/*
* MS-RDPECLIP 2.2.5.3 File Contents Request PDU (CLIPRDR_FILECONTENTS_REQUEST):
* The FILECONTENTS_SIZE and FILECONTENTS_RANGE flags MUST NOT be set at the same time.
*/
if ((fileContentsRequest->dwFlags & (FILECONTENTS_SIZE | FILECONTENTS_RANGE)) ==
(FILECONTENTS_SIZE | FILECONTENTS_RANGE))
{
WLog_Print(file->log, WLOG_ERROR, "invalid CLIPRDR_FILECONTENTS_REQUEST.dwFlags");
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
return cliprdr_file_context_send_file_contents_failure(file, fileContentsRequest);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
if (fileContentsRequest->dwFlags & FILECONTENTS_SIZE)
error = cliprdr_file_context_server_file_size_request(file, fileContentsRequest);
if (fileContentsRequest->dwFlags & FILECONTENTS_RANGE)
error = cliprdr_file_context_server_file_range_request(file, fileContentsRequest);
if (error)
{
WLog_Print(file->log, WLOG_ERROR, "failed to handle CLIPRDR_FILECONTENTS_REQUEST: 0x%08X",
error);
[client,common] cliprdr file copy client to server * better logging of failures * do not keep FILE* open to avoid running out of file handles
2023-02-28 12:26:13 +03:00
return cliprdr_file_context_send_file_contents_failure(file, fileContentsRequest);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
return CHANNEL_RC_OK;
}
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
BOOL cliprdr_file_context_init(CliprdrFileContext* file, CliprdrClientContext* cliprdr)
{
WINPR_ASSERT(file);
WINPR_ASSERT(cliprdr);
cliprdr->custom = file;
file->context = cliprdr;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
cliprdr->ServerLockClipboardData = cliprdr_file_context_lock;
cliprdr->ServerUnlockClipboardData = cliprdr_file_context_unlock;
cliprdr->ServerFileContentsRequest = cliprdr_file_context_server_file_contents_request;
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
cliprdr->ServerFileContentsResponse = cliprdr_file_context_server_file_contents_response;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
#endif
return TRUE;
}
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static void clear_all_selections(CliprdrFileContext* file_context)
{
WINPR_ASSERT(file_context);
WINPR_ASSERT(file_context->inode_table);
HashTable_Lock(file_context->inode_table);
clear_selection(file_context, TRUE, NULL);
HashTable_Clear(file_context->clip_data_table);
HashTable_Unlock(file_context->inode_table);
}
#endif
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
BOOL cliprdr_file_context_uninit(CliprdrFileContext* file, CliprdrClientContext* cliprdr)
{
WINPR_ASSERT(file);
WINPR_ASSERT(cliprdr);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
// Clear all data before the channel is closed
// the cleanup handlers are dependent on a working channel.
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (file->inode_table)
{
clear_no_cdi_entry(file);
clear_all_selections(file);
}
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
#endif
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
HashTable_Clear(file->local_streams);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
file->context = NULL;
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
cliprdr->ServerFileContentsResponse = NULL;
#endif
return TRUE;
}
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
static BOOL cliprdr_file_content_changed_and_update(void* ihash, size_t hsize, const void* data,
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
size_t size)
{
BYTE hash[WINPR_SHA256_DIGEST_LENGTH] = { 0 };
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
if (hsize < sizeof(hash))
return FALSE;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
if (!winpr_Digest(WINPR_MD_SHA256, data, size, hash, sizeof(hash)))
return FALSE;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
const BOOL changed = memcmp(hash, ihash, sizeof(hash)) != 0;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
if (changed)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
memcpy(ihash, hash, sizeof(hash));
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
return changed;
}
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
static BOOL cliprdr_file_server_content_changed_and_update(CliprdrFileContext* file,
const void* data, size_t size)
{
WINPR_ASSERT(file);
return cliprdr_file_content_changed_and_update(file->server_data_hash,
sizeof(file->server_data_hash), data, size);
}
static BOOL cliprdr_file_client_content_changed_and_update(CliprdrFileContext* file,
const void* data, size_t size)
{
WINPR_ASSERT(file);
return cliprdr_file_content_changed_and_update(file->client_data_hash,
sizeof(file->client_data_hash), data, size);
}
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static fuse_ino_t get_next_free_inode(CliprdrFileContext* file_context)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
fuse_ino_t ino = 0;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
ino = file_context->next_ino;
while (ino == 0 || ino == FUSE_ROOT_ID ||
HashTable_GetItemValue(file_context->inode_table, (void*)(UINT_PTR)ino))
++ino;
file_context->next_ino = ino + 1;
return ino;
}
static CliprdrFuseFile* clip_data_dir_new(CliprdrFileContext* file_context, BOOL has_clip_data_id,
UINT32 clip_data_id)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* root_dir = NULL;
CliprdrFuseFile* clip_data_dir = NULL;
size_t path_length = 0;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
clip_data_dir = fuse_file_new();
if (!clip_data_dir)
return NULL;
path_length = 1 + MAX_CLIP_DATA_DIR_LEN + 1;
clip_data_dir->filename_with_root = calloc(path_length, sizeof(char));
if (!clip_data_dir->filename_with_root)
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to allocate filename");
fuse_file_free(clip_data_dir);
return NULL;
}
if (has_clip_data_id)
[client,common] fix format string arguments
2023-07-27 11:37:03 +03:00
_snprintf(clip_data_dir->filename_with_root, path_length, "/%u", (unsigned)clip_data_id);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
else
[client,common] fix format string arguments
2023-07-27 11:37:03 +03:00
_snprintf(clip_data_dir->filename_with_root, path_length, "/%" PRIu64, NO_CLIP_DATA_ID);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
clip_data_dir->filename = strrchr(clip_data_dir->filename_with_root, '/') + 1;
clip_data_dir->ino = get_next_free_inode(file_context);
clip_data_dir->is_directory = TRUE;
clip_data_dir->is_readonly = TRUE;
clip_data_dir->has_clip_data_id = has_clip_data_id;
clip_data_dir->clip_data_id = clip_data_id;
root_dir = file_context->root_dir;
if (!ArrayList_Append(root_dir->children, clip_data_dir))
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to append FUSE file");
fuse_file_free(clip_data_dir);
return NULL;
}
clip_data_dir->parent = root_dir;
if (!HashTable_Insert(file_context->inode_table, (void*)(UINT_PTR)clip_data_dir->ino,
clip_data_dir))
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to insert inode into inode table");
ArrayList_Remove(root_dir->children, clip_data_dir);
fuse_file_free(clip_data_dir);
return NULL;
}
return clip_data_dir;
}
static char* get_parent_path(const char* filepath)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
char* base = NULL;
size_t parent_path_length = 0;
char* parent_path = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
base = strrchr(filepath, '/');
WINPR_ASSERT(base);
while (base > filepath && *base == '/')
--base;
parent_path_length = 1 + base - filepath;
parent_path = calloc(parent_path_length + 1, sizeof(char));
if (!parent_path)
return NULL;
memcpy(parent_path, filepath, parent_path_length);
return parent_path;
}
static BOOL is_fuse_file_not_parent(const void* key, void* value, void* arg)
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
{
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
CliprdrFuseFile* fuse_file = value;
CliprdrFuseFindParentContext* find_context = arg;
if (!fuse_file->is_directory)
return TRUE;
if (strcmp(find_context->parent_path, fuse_file->filename_with_root) == 0)
{
find_context->parent = fuse_file;
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
return FALSE;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
}
return TRUE;
}
static CliprdrFuseFile* get_parent_directory(CliprdrFileContext* file_context, const char* path)
{
CliprdrFuseFindParentContext find_context = { 0 };
WINPR_ASSERT(file_context);
WINPR_ASSERT(path);
find_context.parent_path = get_parent_path(path);
if (!find_context.parent_path)
return NULL;
WINPR_ASSERT(!find_context.parent);
if (HashTable_Foreach(file_context->inode_table, is_fuse_file_not_parent, &find_context))
{
free(find_context.parent_path);
return NULL;
}
WINPR_ASSERT(find_context.parent);
free(find_context.parent_path);
return find_context.parent;
}
static BOOL set_selection_for_clip_data_entry(CliprdrFileContext* file_context,
CliprdrFuseClipDataEntry* clip_data_entry,
[coverity] 1543183 Resource leak
2024-04-11 12:16:46 +03:00
const FILEDESCRIPTORW* files, UINT32 n_files)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* clip_data_dir = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(clip_data_entry);
WINPR_ASSERT(files);
clip_data_dir = clip_data_entry->clip_data_dir;
WINPR_ASSERT(clip_data_dir);
if (clip_data_entry->has_clip_data_id)
WLog_Print(file_context->log, WLOG_DEBUG, "Setting selection for clipDataId %u",
clip_data_entry->clip_data_id);
else
WLog_Print(file_context->log, WLOG_DEBUG, "Setting selection");
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
// NOLINTBEGIN(clang-analyzer-unix.Malloc) HashTable_Insert owns fuse_file
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
for (UINT32 i = 0; i < n_files; ++i)
{
[coverity] 1543183 Resource leak
2024-04-11 12:16:46 +03:00
const FILEDESCRIPTORW* file = &files[i];
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* fuse_file = NULL;
char* filename = NULL;
size_t path_length = 0;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_file = fuse_file_new();
if (!fuse_file)
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to create FUSE file");
clear_entry_selection(clip_data_entry);
return FALSE;
}
filename = ConvertWCharToUtf8Alloc(file->cFileName, NULL);
if (!filename)
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to convert filename");
fuse_file_free(fuse_file);
clear_entry_selection(clip_data_entry);
return FALSE;
}
for (size_t j = 0; filename[j]; ++j)
{
if (filename[j] == '\\')
filename[j] = '/';
}
path_length = strlen(clip_data_dir->filename_with_root) + 1 + strlen(filename) + 1;
fuse_file->filename_with_root = calloc(path_length, sizeof(char));
if (!fuse_file->filename_with_root)
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to allocate filename");
free(filename);
fuse_file_free(fuse_file);
clear_entry_selection(clip_data_entry);
return FALSE;
}
_snprintf(fuse_file->filename_with_root, path_length, "%s/%s",
clip_data_dir->filename_with_root, filename);
free(filename);
fuse_file->filename = strrchr(fuse_file->filename_with_root, '/') + 1;
fuse_file->parent = get_parent_directory(file_context, fuse_file->filename_with_root);
if (!fuse_file->parent)
{
WLog_Print(file_context->log, WLOG_ERROR, "Found no parent for FUSE file");
fuse_file_free(fuse_file);
clear_entry_selection(clip_data_entry);
return FALSE;
}
if (!ArrayList_Append(fuse_file->parent->children, fuse_file))
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to append FUSE file");
fuse_file_free(fuse_file);
clear_entry_selection(clip_data_entry);
return FALSE;
}
fuse_file->list_idx = i;
fuse_file->ino = get_next_free_inode(file_context);
fuse_file->has_clip_data_id = clip_data_entry->has_clip_data_id;
fuse_file->clip_data_id = clip_data_entry->clip_data_id;
if (file->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
fuse_file->is_directory = TRUE;
if (file->dwFileAttributes & FILE_ATTRIBUTE_READONLY)
fuse_file->is_readonly = TRUE;
if (file->dwFlags & FD_FILESIZE)
{
fuse_file->size = ((UINT64)file->nFileSizeHigh << 32) + file->nFileSizeLow;
fuse_file->has_size = TRUE;
}
if (file->dwFlags & FD_WRITESTIME)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
UINT64 filetime = 0;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
filetime = file->ftLastWriteTime.dwHighDateTime;
filetime <<= 32;
filetime += file->ftLastWriteTime.dwLowDateTime;
fuse_file->last_write_time_unix =
filetime / (10 * 1000 * 1000) - WIN32_FILETIME_TO_UNIX_EPOCH;
fuse_file->has_last_write_time = TRUE;
}
if (!HashTable_Insert(file_context->inode_table, (void*)(UINT_PTR)fuse_file->ino,
fuse_file))
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to insert inode into inode table");
fuse_file_free(fuse_file);
clear_entry_selection(clip_data_entry);
return FALSE;
}
}
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
// NOLINTEND(clang-analyzer-unix.Malloc) HashTable_Insert owns fuse_file
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (clip_data_entry->has_clip_data_id)
WLog_Print(file_context->log, WLOG_DEBUG, "Selection set for clipDataId %u",
clip_data_entry->clip_data_id);
else
WLog_Print(file_context->log, WLOG_DEBUG, "Selection set");
return TRUE;
}
static BOOL update_exposed_path(CliprdrFileContext* file_context, wClipboard* clip,
CliprdrFuseClipDataEntry* clip_data_entry)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
wClipboardDelegate* delegate = NULL;
CliprdrFuseFile* clip_data_dir = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(clip);
WINPR_ASSERT(clip_data_entry);
delegate = ClipboardGetDelegate(clip);
WINPR_ASSERT(delegate);
clip_data_dir = clip_data_entry->clip_data_dir;
WINPR_ASSERT(clip_data_dir);
free(file_context->exposed_path);
file_context->exposed_path = GetCombinedPath(file_context->path, clip_data_dir->filename);
if (file_context->exposed_path)
WLog_Print(file_context->log, WLOG_DEBUG, "Updated exposed path to \"%s\"",
file_context->exposed_path);
delegate->basePath = file_context->exposed_path;
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
return delegate->basePath != NULL;
}
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
#endif
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
BOOL cliprdr_file_context_update_server_data(CliprdrFileContext* file_context, wClipboard* clip,
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
const void* data, size_t size)
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
{
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseClipDataEntry* clip_data_entry = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
FILEDESCRIPTORW* files = NULL;
UINT32 n_files = 0;
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
WINPR_ASSERT(file_context);
WINPR_ASSERT(clip);
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (cliprdr_parse_file_list(data, size, &files, &n_files))
{
WLog_Print(file_context->log, WLOG_ERROR, "Failed to parse file list");
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
return FALSE;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
}
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Lock(file_context->inode_table);
if (does_server_support_clipdata_locking(file_context))
clip_data_entry = HashTable_GetItemValue(
file_context->clip_data_table, (void*)(UINT_PTR)file_context->current_clip_data_id);
else
clip_data_entry = file_context->clip_data_entry_without_id;
WINPR_ASSERT(clip_data_entry);
clear_entry_selection(clip_data_entry);
WINPR_ASSERT(!clip_data_entry->clip_data_dir);
clip_data_entry->clip_data_dir =
clip_data_dir_new(file_context, does_server_support_clipdata_locking(file_context),
file_context->current_clip_data_id);
if (!clip_data_entry->clip_data_dir)
{
HashTable_Unlock(file_context->inode_table);
free(files);
[client,common] simplify file clipboard API
2023-03-01 11:12:02 +03:00
return FALSE;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
}
if (!update_exposed_path(file_context, clip, clip_data_entry))
{
HashTable_Unlock(file_context->inode_table);
free(files);
return FALSE;
}
if (!set_selection_for_clip_data_entry(file_context, clip_data_entry, files, n_files))
{
HashTable_Unlock(file_context->inode_table);
free(files);
return FALSE;
}
HashTable_Unlock(file_context->inode_table);
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
[coverity] 1543183 Resource leak
2024-04-11 12:16:46 +03:00
free(files);
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
return TRUE;
#else
return FALSE;
#endif
[client,x11] split file clipboard to own struct * split file clipboard to own file * check for changed file data in cliprdr_file_context_update_data, prevents duplidate entries in fuse filesystem
2023-02-25 14:42:04 +03:00
}
void* cliprdr_file_context_get_context(CliprdrFileContext* file)
{
WINPR_ASSERT(file);
return file->clipboard;
}
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
void cliprdr_file_session_terminate(CliprdrFileContext* file, BOOL stop_thread)
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
{
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (!file)
return;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
WINPR_ASSERT(file->fuse_stop_sync);
WLog_Print(file->log, WLOG_DEBUG, "Setting FUSE exit flag");
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (file->fuse_sess)
fuse_session_exit(file->fuse_sess);
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
if (stop_thread)
{
WLog_Print(file->log, WLOG_DEBUG, "Setting FUSE stop event");
SetEvent(file->fuse_stop_sync);
}
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
/* not elegant but works for umounting FUSE
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
fuse_chan must receive an oper buf to unblock fuse_session_receive_buf function.
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
*/
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
WLog_Print(file->log, WLOG_DEBUG, "Forcing FUSE to check exit flag");
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
winpr_PathFileExists(file->path);
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
}
void cliprdr_file_context_free(CliprdrFileContext* file)
{
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (!file)
return;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
if (file->inode_table)
{
clear_no_cdi_entry(file);
clear_all_selections(file);
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (file->fuse_thread)
{
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
WINPR_ASSERT(file->fuse_stop_sync);
WLog_Print(file->log, WLOG_DEBUG, "Stopping FUSE thread");
client/cliprdr_file: Do not deadlock with FUSE2 when stopping fuse loop FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit.
2023-08-03 18:15:28 +03:00
cliprdr_file_session_terminate(file, TRUE);
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
WLog_Print(file->log, WLOG_DEBUG, "Waiting on FUSE thread");
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
WaitForSingleObject(file->fuse_thread, INFINITE);
CloseHandle(file->fuse_thread);
}
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
if (file->fuse_stop_sync)
CloseHandle(file->fuse_stop_sync);
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
if (file->fuse_start_sync)
CloseHandle(file->fuse_start_sync);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
HashTable_Free(file->request_table);
HashTable_Free(file->clip_data_table);
HashTable_Free(file->inode_table);
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
HashTable_Free(file->local_streams);
winpr_RemoveDirectory(file->path);
free(file->path);
[client,common] fixed winpr clipboard locking
2023-02-28 13:37:42 +03:00
free(file->exposed_path);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
free(file);
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
}
static BOOL create_base_path(CliprdrFileContext* file)
{
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
WINPR_ASSERT(file);
char base[64] = { 0 };
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
_snprintf(base, sizeof(base), "com.freerdp.client.cliprdr.%" PRIu32, GetCurrentProcessId());
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
file->path = GetKnownSubPath(KNOWN_PATH_TEMP, base);
if (!file->path)
return FALSE;
if (!winpr_PathFileExists(file->path) && !winpr_PathMakePath(file->path, 0))
{
WLog_Print(file->log, WLOG_ERROR, "Failed to create directory '%s'", file->path);
return FALSE;
}
return TRUE;
}
static void cliprdr_local_file_free(CliprdrLocalFile* file)
{
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
const CliprdrLocalFile empty = { 0 };
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (!file)
return;
if (file->fp)
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
{
WLog_Print(file->context->log, WLOG_DEBUG, "closing file %s, discarding entry", file->name);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
fclose(file->fp);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
free(file->name);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
*file = empty;
}
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
static BOOL cliprdr_local_file_new(CliprdrFileContext* context, CliprdrLocalFile* f,
const char* path)
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
{
const CliprdrLocalFile empty = { 0 };
WINPR_ASSERT(f);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WINPR_ASSERT(context);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
WINPR_ASSERT(path);
*f = empty;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
f->context = context;
[winpr,clipboard] fix url unescape for file uri
2023-05-11 14:03:39 +03:00
f->name = winpr_str_url_decode(path, strlen(path));
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
if (!f->name)
goto fail;
return TRUE;
fail:
cliprdr_local_file_free(f);
return FALSE;
}
static void cliprdr_local_files_free(CliprdrLocalStream* stream)
{
WINPR_ASSERT(stream);
for (size_t x = 0; x < stream->count; x++)
cliprdr_local_file_free(&stream->files[x]);
free(stream->files);
stream->files = NULL;
stream->count = 0;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
static void cliprdr_local_stream_free(void* obj)
{
CliprdrLocalStream* stream = (CliprdrLocalStream*)obj;
if (stream)
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
cliprdr_local_files_free(stream);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
free(stream);
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
static BOOL append_entry(CliprdrLocalStream* stream, const char* path)
{
CliprdrLocalFile* tmp = realloc(stream->files, sizeof(CliprdrLocalFile) * (stream->count + 1));
if (!tmp)
return FALSE;
stream->files = tmp;
CliprdrLocalFile* f = &stream->files[stream->count++];
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
return cliprdr_local_file_new(stream->context, f, path);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
}
static BOOL is_directory(const char* path)
{
WCHAR* wpath = ConvertUtf8ToWCharAlloc(path, NULL);
if (!wpath)
return FALSE;
HANDLE hFile =
CreateFileW(wpath, 0, FILE_SHARE_DELETE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
free(wpath);
if (hFile == INVALID_HANDLE_VALUE)
return FALSE;
BY_HANDLE_FILE_INFORMATION fileInformation = { 0 };
const BOOL status = GetFileInformationByHandle(hFile, &fileInformation);
CloseHandle(hFile);
if (!status)
return FALSE;
misc: More int to BOOL conversion fixes This is a follow up to #9129. This PR fixes some problematic `int` to `BOOL` conversions that might cause overflows when checking for bit flags.
2023-07-04 10:26:52 +03:00
return (fileInformation.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) ? TRUE : FALSE;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
}
static BOOL add_directory(CliprdrLocalStream* stream, const char* path)
{
char* wildcardpath = GetCombinedPath(path, "*");
if (!wildcardpath)
return FALSE;
WCHAR* wpath = ConvertUtf8ToWCharAlloc(wildcardpath, NULL);
free(wildcardpath);
if (!wpath)
return FALSE;
WIN32_FIND_DATAW FindFileData = { 0 };
HANDLE hFind = FindFirstFileW(wpath, &FindFileData);
free(wpath);
if (hFind == INVALID_HANDLE_VALUE)
return FALSE;
BOOL rc = FALSE;
char* next = NULL;
fixed WCHAR constants, use endian safe definitions
2023-12-12 11:18:30 +03:00
WCHAR dotbuffer[6] = { 0 };
WCHAR dotdotbuffer[6] = { 0 };
const WCHAR* dot = InitializeConstWCharFromUtf8(".", dotbuffer, ARRAYSIZE(dotbuffer));
const WCHAR* dotdot = InitializeConstWCharFromUtf8("..", dotdotbuffer, ARRAYSIZE(dotdotbuffer));
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
do
{
if (_wcscmp(FindFileData.cFileName, dot) == 0)
continue;
if (_wcscmp(FindFileData.cFileName, dotdot) == 0)
continue;
char cFileName[MAX_PATH] = { 0 };
ConvertWCharNToUtf8(FindFileData.cFileName, ARRAYSIZE(FindFileData.cFileName), cFileName,
ARRAYSIZE(cFileName));
free(next);
next = GetCombinedPath(path, cFileName);
if (!next)
goto fail;
if (!append_entry(stream, next))
goto fail;
if (is_directory(next))
{
if (!add_directory(stream, next))
goto fail;
}
} while (FindNextFileW(hFind, &FindFileData));
rc = TRUE;
fail:
free(next);
FindClose(hFind);
return rc;
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
static BOOL cliprdr_local_stream_update(CliprdrLocalStream* stream, const char* data, size_t size)
{
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
BOOL rc = FALSE;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
WINPR_ASSERT(stream);
if (size == 0)
return TRUE;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
cliprdr_local_files_free(stream);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
stream->files = calloc(size, sizeof(CliprdrLocalFile));
if (!stream->files)
return FALSE;
char* copy = strndup(data, size);
if (!copy)
return FALSE;
char* ptr = strtok(copy, "\r\n");
while (ptr)
{
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
const char* name = ptr;
if (strncmp("file:///", ptr, 8) == 0)
name = &ptr[7];
else if (strncmp("file:/", ptr, 6) == 0)
name = &ptr[5];
if (!append_entry(stream, name))
goto fail;
if (is_directory(name))
{
const BOOL res = add_directory(stream, name);
if (!res)
goto fail;
}
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
ptr = strtok(NULL, "\r\n");
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
rc = TRUE;
fail:
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
free(copy);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
return rc;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
CliprdrLocalStream* cliprdr_local_stream_new(CliprdrFileContext* context, UINT32 lockId,
const char* data, size_t size)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
{
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WINPR_ASSERT(context);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
CliprdrLocalStream* stream = calloc(1, sizeof(CliprdrLocalStream));
if (!stream)
return NULL;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
stream->context = context;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (!cliprdr_local_stream_update(stream, data, size))
goto fail;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
stream->lockId = lockId;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
return stream;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
fail:
cliprdr_local_stream_free(stream);
return NULL;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
}
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
static UINT32 UINTPointerHash(const void* id)
{
WINPR_ASSERT(id);
return *((const UINT32*)id);
}
static BOOL UINTPointerCompare(const void* pointer1, const void* pointer2)
{
if (!pointer1 || !pointer2)
return pointer1 == pointer2;
const UINT32* a = pointer1;
const UINT32* b = pointer2;
return *a == *b;
}
static void* UINTPointerClone(const void* other)
{
const UINT32* src = other;
if (!src)
return NULL;
UINT32* copy = calloc(1, sizeof(UINT32));
if (!copy)
return NULL;
*copy = *src;
return copy;
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
static CliprdrFuseFile* fuse_file_new_root(CliprdrFileContext* file_context)
{
[clang-tidy] cppcoreguidelines-init-variables
2024-01-23 18:49:54 +03:00
CliprdrFuseFile* root_dir = NULL;
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
root_dir = fuse_file_new();
if (!root_dir)
return NULL;
root_dir->filename_with_root = calloc(2, sizeof(char));
if (!root_dir->filename_with_root)
{
fuse_file_free(root_dir);
return NULL;
}
_snprintf(root_dir->filename_with_root, 2, "/");
root_dir->filename = root_dir->filename_with_root;
root_dir->ino = FUSE_ROOT_ID;
root_dir->is_directory = TRUE;
root_dir->is_readonly = TRUE;
if (!HashTable_Insert(file_context->inode_table, (void*)(UINT_PTR)root_dir->ino, root_dir))
{
fuse_file_free(root_dir);
return NULL;
}
return root_dir;
}
#endif
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
CliprdrFileContext* cliprdr_file_context_new(void* context)
{
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
CliprdrFileContext* file = calloc(1, sizeof(CliprdrFileContext));
if (!file)
return NULL;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
file->log = WLog_Get(CLIENT_TAG("common.cliprdr.file"));
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
file->clipboard = context;
file->local_streams = HashTable_New(FALSE);
if (!file->local_streams)
goto fail;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
if (!HashTable_SetHashFunction(file->local_streams, UINTPointerHash))
goto fail;
wObject* hkobj = HashTable_KeyObject(file->local_streams);
WINPR_ASSERT(hkobj);
hkobj->fnObjectEquals = UINTPointerCompare;
hkobj->fnObjectFree = free;
hkobj->fnObjectNew = UINTPointerClone;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
wObject* hobj = HashTable_ValueObject(file->local_streams);
WINPR_ASSERT(hobj);
hobj->fnObjectFree = cliprdr_local_stream_free;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
file->inode_table = HashTable_New(FALSE);
file->clip_data_table = HashTable_New(FALSE);
file->request_table = HashTable_New(FALSE);
if (!file->inode_table || !file->clip_data_table || !file->request_table)
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
goto fail;
[cliprdr,common] fix file_context->request_table
2024-04-15 12:41:23 +03:00
{
wObject* ctobj = HashTable_ValueObject(file->request_table);
WINPR_ASSERT(ctobj);
ctobj->fnObjectFree = free;
}
{
wObject* ctobj = HashTable_ValueObject(file->clip_data_table);
WINPR_ASSERT(ctobj);
ctobj->fnObjectFree = clip_data_entry_free;
}
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
X11/cliprdr: Rework server to client clipboard handling The purpose of clipboard data locking is to make the other peer retaining the current file list until a pending paste operation is done, even though the clipboard selection changed. As it may be difficult to determine, when a lock is needed, imitate the same behaviour as mstsc: When the server side supports clipboard data locking, always attempt to lock the file list on the server regardless of what is advertised in a FormatList PDU. The Lock Clipboard Data PDU can even be already sent, before the Format List Response PDU is sent. This is also what mstsc, does: First, lock the new (potential) file list, then unlock the file list, when the pending paste operation is done. So, rework the current clipboard implementation in that direction. Since the implementation for timeouts for old file lists is a bit hard, for now always force unlock pending locks, when the selection changes. However, timeouts for old file lists can still be added in the future. The reworked clipboard handling is done with the help of three hash tables: 1. The inode table: This hash table manages all inodes for each file. The keys in this table are the inodes themselves, while the values the files and directories and their attributes (file size, last write time, etc.). 2. The clipdata table: This table manages the locks for each file list. The keys in this table represent the clip data id and the values the clip data entries, which have a reference to the clip data dir, a directory containing the whole selection, and some helper attributes, like the clip data id itself. 3. The request table: Every file size or file range request is managed here. When a FileContentsRequest is made, its stream id with the respective details are added to this table. When a response is received, these details can then be easily looked up here.
2023-07-19 11:38:33 +03:00
file->root_dir = fuse_file_new_root(file);
if (!file->root_dir)
[client,common] fixed compile without fuse
2023-02-28 15:36:59 +03:00
goto fail;
#endif
[client,common] fixed winpr clipboard locking
2023-02-28 13:37:42 +03:00
if (!create_base_path(file))
goto fail;
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
if (!(file->fuse_start_sync = CreateEvent(NULL, TRUE, FALSE, NULL)))
goto fail;
client/cliprdr_file: Do not destroy FUSE session while using it When invalidating inodes, it is obligatory, that the session was not destroyed yet. So, in case of the FUSE loop stops before the session stops wait with the destroyal of the session, until it is clear, that it is not used anymore.
2023-08-02 20:36:38 +03:00
if (!(file->fuse_stop_sync = CreateEvent(NULL, TRUE, FALSE, NULL)))
goto fail;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (!(file->fuse_thread = CreateThread(NULL, 0, cliprdr_file_fuse_thread, file, 0, NULL)))
goto fail;
client/cliprdr_file: Fix build when using FUSE2 instead of FUSE3 To invalidate inodes, FUSE2 uses a FUSE channel handle, while FUSE3 uses the FUSE session. So, ensure the correct handle is passed to the respective API calls.
2023-08-02 22:52:32 +03:00
if (WaitForSingleObject(file->fuse_start_sync, INFINITE) == WAIT_FAILED)
WLog_Print(file->log, WLOG_ERROR, "Failed to wait for start sync");
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
#endif
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
return file;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
fail:
[build] fix Wmismatched-deallocator warnings With custom malloc function attributes the fail path in the _New functions produces warnings due to allocator mismatches. Silence them.
2024-02-04 13:11:29 +03:00
WINPR_PRAGMA_DIAG_PUSH
WINPR_PRAGMA_DIAG_IGNORED_MISMATCHED_DEALLOC
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
cliprdr_file_context_free(file);
[build] fix Wmismatched-deallocator warnings With custom malloc function attributes the fail path in the _New functions produces warnings due to allocator mismatches. Silence them.
2024-02-04 13:11:29 +03:00
WINPR_PRAGMA_DIAG_POP
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
return NULL;
}
BOOL local_stream_discard(const void* key, void* value, void* arg)
{
CliprdrFileContext* file = arg;
CliprdrLocalStream* stream = value;
WINPR_ASSERT(file);
WINPR_ASSERT(stream);
if (!stream->locked)
HashTable_Remove(file->local_streams, key);
return TRUE;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
}
BOOL cliprdr_file_context_clear(CliprdrFileContext* file)
{
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WINPR_ASSERT(file);
client/cliprdr_file: Fix small typo
2023-04-01 11:38:43 +03:00
WLog_Print(file->log, WLOG_DEBUG, "clear file clipboard...");
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
[client,common] fix file clipboard locking
2023-04-04 11:51:01 +03:00
HashTable_Lock(file->local_streams);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
HashTable_Foreach(file->local_streams, local_stream_discard, file);
[client,common] fix file clipboard locking
2023-04-04 11:51:01 +03:00
HashTable_Unlock(file->local_streams);
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
memset(file->server_data_hash, 0, sizeof(file->server_data_hash));
memset(file->client_data_hash, 0, sizeof(file->client_data_hash));
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
return TRUE;
}
BOOL cliprdr_file_context_update_client_data(CliprdrFileContext* file, const char* data,
size_t size)
{
BOOL rc = FALSE;
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WINPR_ASSERT(file);
if (!cliprdr_file_client_content_changed_and_update(file, data, size))
return TRUE;
[client,common] fix fuse inode creation, add logging
2023-03-01 11:31:03 +03:00
if (!cliprdr_file_context_clear(file))
return FALSE;
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
UINT32 lockId = file->local_lock_id;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
HashTable_Lock(file->local_streams);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
CliprdrLocalStream* stream = HashTable_GetItemValue(file->local_streams, &lockId);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
WLog_Print(file->log, WLOG_DEBUG, "update client file list (stream=%p)...", stream);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
if (stream)
rc = cliprdr_local_stream_update(stream, data, size);
else
{
[client,common] fuse clipboard server to client
2023-02-28 00:31:15 +03:00
stream = cliprdr_local_stream_new(file, lockId, data, size);
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
rc = HashTable_Insert(file->local_streams, &stream->lockId, stream);
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
if (!rc)
cliprdr_local_stream_free(stream);
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
[clang-tidy] clang-analyzer-unix.Malloc
2024-01-24 10:21:47 +03:00
// HashTable_Insert owns stream
// NOLINTNEXTLINE(clang-analyzer-unix.Malloc)
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
HashTable_Unlock(file->local_streams);
return rc;
}
UINT32 cliprdr_file_context_current_flags(CliprdrFileContext* file)
{
WINPR_ASSERT(file);
if ((file->file_capability_flags & CB_STREAM_FILECLIP_ENABLED) == 0)
return 0;
if (!file->file_formats_registered)
return 0;
[client,common] refactored fuse clipboard * use proper permissions (no read/write for group and others) * handle streamID for multiple simultaneous copy/paste operations * properly handle requests with a queue
2023-02-26 14:53:23 +03:00
return CB_STREAM_FILECLIP_ENABLED | CB_FILECLIP_NO_FILE_PATHS |
CB_HUGE_FILE_SUPPORT_ENABLED; // | CB_CAN_LOCK_CLIPDATA;
[client] move file clipboard to client common
2023-02-25 18:57:52 +03:00
}
BOOL cliprdr_file_context_set_locally_available(CliprdrFileContext* file, BOOL available)
{
WINPR_ASSERT(file);
file->file_formats_registered = available;
return TRUE;
}
BOOL cliprdr_file_context_remote_set_flags(CliprdrFileContext* file, UINT32 flags)
{
WINPR_ASSERT(file);
file->file_capability_flags = flags;
return TRUE;
}
UINT32 cliprdr_file_context_remote_get_flags(CliprdrFileContext* file)
{
WINPR_ASSERT(file);
return file->file_capability_flags;
remove wClipboardDelegate
2023-02-25 18:46:12 +03:00
}
[client,common] fix file copy client to server
2023-02-27 16:50:43 +03:00
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
BOOL cliprdr_file_context_has_local_support(CliprdrFileContext* file)
{
WINPR_UNUSED(file);
[client,common] drop fuse2 support
2023-10-10 13:46:59 +03:00
#if defined(WITH_FUSE)
[cliprdr] deactivate local file paste if not supported if the file clipboard was compiled without FUSE do not announce the availability.
2023-02-28 11:31:09 +03:00
return TRUE;
#else
return FALSE;
#endif
}
Reference in New Issue Copy Permalink