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.
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.
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.
The purpose of clipboard data locking is to make the other peer
retaining the current file list until a pending paste operation is done,
even though the clipboard selection changed.
As it may be difficult to determine, when a lock is needed, imitate the
same behaviour as mstsc:
When the server side supports clipboard data locking, always attempt to
lock the file list on the server regardless of what is advertised in a
FormatList PDU.
The Lock Clipboard Data PDU can even be already sent, before the
Format List Response PDU is sent.
This is also what mstsc, does: First, lock the new (potential) file
list, then unlock the file list, when the pending paste operation is
done.
So, rework the current clipboard implementation in that direction.
Since the implementation for timeouts for old file lists is a bit hard,
for now always force unlock pending locks, when the selection changes.
However, timeouts for old file lists can still be added in the future.
The reworked clipboard handling is done with the help of three hash
tables:
1. The inode table: This hash table manages all inodes for each file.
The keys in this table are the inodes themselves, while the values
the files and directories and their attributes (file size, last write
time, etc.).
2. The clipdata table: This table manages the locks for each file list.
The keys in this table represent the clip data id and the values the
clip data entries, which have a reference to the clip data dir, a
directory containing the whole selection, and some helper attributes,
like the clip data id itself.
3. The request table: Every file size or file range request is managed
here. When a FileContentsRequest is made, its stream id with the
respective details are added to this table. When a response is
received, these details can then be easily looked up here.
* use proper permissions (no read/write for group and others)
* handle streamID for multiple simultaneous copy/paste operations
* properly handle requests with a queue
