Every uri in the x-special/gnome-copied-files mime type is separated by
a '\n' char.
However, not every line ends with '\n'. The last line MUST not include
the new line character.
Currently, when a local uri-list is converted into a FILEDESCRIPTORW
list, WinPR doesn't submit the last write time for each file.
The result of this is that the last write time of each file on the
other peer will have the current time and not the actual last write
time that is present on the peer, where the files were copied from.
Fix this by also writing the last write time in addition to the
FD_WRITESTIME flag.
The file clipboard delegate needs a base URI to operate on for
systems that are not WIN32. Added that to the context and abort
conversion, if that is not set. (currently not fully implemented)
ConvertFromUnicode ignores '\0' sequences when the length of the input
string is given. Clipboard strings may be larger than the actual string
length and padded with random data leading to decoding errors.
Limit the length to the first occurrence of a '\0'.
FreeRDP/winpr/libwinpr/clipboard/posix.c:397:20: error: conflicting types for ‘basename’
static const char* basename(const char* name)
^
In file included from FreeRDP/winpr/include/winpr/collections.h:25:0,
from FreeRDP/winpr/libwinpr/clipboard/posix.c:37:
/usr/include/string.h:599:14: note: previous declaration of ‘basename’ was here
extern char *basename (const char *__filename) __THROW __nonnull ((1));
This preprocessor definition has been initially intended to disable some
computationally expensive logging, however it turned out that there is
not much computation involved in the resulting implementation of new
wClipboard subsystems. Therefore we do not actually need the compilation
option, the logs can be filtered by "com.winpr.wclipboard.*" tag at
runtime if necessary. So drop the WITH_DEBUG_WCLIPBOARD CMake option and
convert all detailed logs to use WLOG_TRACE level via WLog_VRB macro.
Another issue revealed during testing is that older Windows systems
cannot handle the reserved file names well. While Windows 8 and 10 are
fine (they silently abort the file transfer), using reserved names with
Windows 7 can flat out crash explorer.exe or result into weird error
messages like "fatal error: 0x00000000 ERROR_SUCCESS".
This is not required by MS-RDPECLIP specification, but we should try to
avoid this issue as not using reserved file names seems to be assumed
a common sense in Windows protocols.
The most convenient way to handle the issue would be on wClipboard level
so that WinPR's clients do not bother with it. We should prohibit the
reserved names from being used in FILEDESCRIPTOR, failing the conversion
if we see such a file.
POSIX subsystem (the only one at the moment) handles remote file names
in two places so move the Unicode conversion and the new validation
check into a separate function.
The reserved file name predicate is placed into <winpr/file.h> so that
it can be used in other places too. For example, other wClipboard local
file subsystems will need it. (It would be really nice to enforce this
check somewhere in the common code, so that the subsystems can't miss
it, but other places can miss some errors thus we're doing it here, as
early as possible.)
The predicate acts on separate file name components rather than full
file names because the backslash is a reserved character too. If we
process full file names this can result in phantom directory entry in
the remote file name. Not to say that handling ready-made components
spares us from splitting the full file name to extract them :)
The implementation is... a bit verbose, but that's fine by me. In the
absence of functions for case-insensitive wide string comparison and
the need to check for the [0-9] at the end of some file names this is
quite readable. Thanks to FAT and NTFS for being case-insensitive and
to MS-DOS for having reserved file names in the first place.
One important point in the cliprdr protocol is that the peers are not
allowed to request file sizes and ranges if the clipboard content
changes. File locking should be used to gain this ability. However, our
file list is still accessible after new data is set into wClipboard.
Catch this error by storing the sequence number of the file list when it
is set and checking that it is still in effect at the time when the
client requests file sizes or ranges. There is a small chance of false
positives when the sequence number overflows, but I guess we can safely
ignore it.
