POSIX clipboard (wClipboard) produces on master invalid file lists

[pnowack]

When trying to copy paste a folder (containing files) with xfreerdp3 (master), the submitted file list is invalid. A lot of file-replace dialogs are shown for each entry (where as the former file seems to always be 0 Bytes) and the attributes (the creation date) is invalid.

Reproduction steps:

1. Prepare a folder with files, you can clone the ogon-channels repo for this (small repo, lots of files).
2. Connect with xfreerdp3 (master) to an RDP server
3. Copy the folder on the client side and paste it on the server side

Observation:

You get a lot of file-replace dialogs and the file creation attribute is invalid. Also, the contents of the folder themselves are in the top level directory too.
These issue don't happen with xfreerdp2 (stable-2.0 branch).

Screencast of the issue:

Bildschirmaufzeichnung.vom.2022-10-27.09-15-11.webm

In the screencast, first xfreerdp3 (master) is used to try to copy-paste the folder (where you can see, that it fails with the errors mentioned above).
Then xfreerdp2 (stable-2.0) is used, where everything works fine.

[pnowack]

The issue is likely in the POSIX clipboard part. A month or two ago, things just worked fine. So, any recent PRs in that area are possible candidates where things went wrong.

[akallabeth]

@pnowack ok, can not reproduce here on fedora 36 with gnome/nautilus. (copied my whole download folder with many subolders, android studio, ... in it)

[pnowack]

@akallabeth that's weird. In any case, the error is with xfreerdp from the master branch and the nautilus version on the client side here 43.0 (am on Arch)
nautilus was ported to GTK4 in 43, but should not affect xfreerdp in any case here, and xfreerdp from the stable-2.0 branch is, as seen in the screencast unaffected by that.

In the screencast, where I close the xfreerdp3 window, the terminal output is seen and lots of Find NextFile failed (18) is shown, does this give a clue here?

[pnowack]

Could you retry this with the ogon-channels repo here, which I use here too? In case nautilus 43 really brings an additional factor here (although it works fine with the stable-2.0 version), Ubuntu 22.10 also has GNOME 43.

can not reproduce here on fedora 36 with gnome/nautilus.

Does this also apply to the file changed dates here (i.e. not 1601, but actual date, that is also used on the client side for the respective file(s))?