Xpra: Ticket #2456: xpra start handle name normalization

I accidentally discovered that, I can "bring" files to my client machine by xdg-opening them! :-D :-D

Super exciting!!! I wish I knew of the shortcut earlier.

However, I think you haven't solved the filename normalization discrepancies:

2019-10-19 13:07:25,204 Unhandled error while processing a 'send-file' packet from peer using <bound method FileTransferHandler._process_send_file of gtk3.client>
Traceback (most recent call last):
  File "E:\Xpra\trunk\src/xpra/client/client_base.py", line 948, in process_packet
  File "E:\Xpra\trunk\src/xpra/net/file_transfer.py", line 354, in _process_send_file
  File "E:\Xpra\trunk\src/xpra/net/file_transfer.py", line 66, in safe_open_download_file
OSError: [Errno 22] Invalid argument: '~\\Downloads\\a-2019-10-18 14:47:36.511034.mp4'


Sun, 20 Oct 2019 14:23:29 GMT - Antoine Martin: owner changed

I assume that the client is MS Windows? What version? What is the server? Works fine for me, the ~\Downloads directory correctly gets expanded to a path.

Some minor improvements in r24206 + r24207, does that help? (new 4.0 beta win32 build) If you still have problems, can you add -d file to your client command line?


Sun, 20 Oct 2019 14:44:34 GMT - stdedos:

You can check them eg from #2455. I am on the phone and copy pasting them here is kind of hard.


Sun, 20 Oct 2019 14:49:19 GMT - stdedos:

Oh, oh, apologies! 😁

The problem (I think) is with the filename, not with the directory path


Sun, 20 Oct 2019 15:06:32 GMT - totaamwin32: owner, status changed

The problem (I think) is with the filename, not with the directory path

I think you're right. Still not sure why the path doesn't look expanded, but trying this by hand I get:

>>> os.open("E:\\a-2019-10-18 14:36.511034.mp4", os.O_CREAT | os.O_RDWR | os.O_EXCL | os.O_BINARY)
7
>>> os.open("E:\\a-2019-10-18 14:47:36.511034.mp4", os.O_CREAT | os.O_RDWR | os.O_EXCL | os.O_BINARY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'E:\\a-2019-10-18 14:47:36.511034.mp4'

Why does the first one work and the second one doesn't?? The 3 extra characters :47 are all already present in the first string!


Sun, 20 Oct 2019 15:16:51 GMT - totaamwin32:

mswindows is weird:

>>> os.open("E:\\a-1:2.foo.mp4", os.O_CREAT | os.O_RDWR | os.O_EXCL | os.O_BINARY)
9
>>> os.open("E:\\a-1:2:3.foo.mp4", os.O_CREAT | os.O_RDWR | os.O_EXCL | os.O_BINARY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'E:\\a-1:2:3.foo.mp4'

Only a single : character is allowed?

According to Naming Files, Paths, and Namespaces, it shouldn't be allowed at all?


Sun, 20 Oct 2019 15:38:18 GMT - totaamwin32: owner, status changed

Should be fixed in r24216.

Please try the latest beta win32 build.


Mon, 21 Oct 2019 10:02:25 GMT - stdedos:

(..) According to Naming Files, Paths, and Namespaces, it shouldn't be allowed at all?

Well ... try to write something into that file, and see what is the output on the filesystem? :-D

Replying to totaamwin32:

Should be fixed in r24216.

Please try the latest beta win32 build.

Well, not exactly

2019-10-21 12:53:53,011 Error: failed to save downloaded file
2019-10-21 12:53:53,014  [Errno 2] No such file or directory: 'C_\\Users\\user\\Downloads\\a-2019-10-18 14-35-59.713705.mp4'

If you are constructing the path like os.path.join(os.path.expanduser("~"), 'Downloads', file_name), then maybe do os.path.join(os.path.expanduser("~"), 'Downloads', sanitize_filename(file_name)) instead of sanitize_filename(os.path.join(os.path.expanduser("~"), 'Downloads', file_name))


Mon, 21 Oct 2019 11:30:32 GMT - Antoine Martin: status changed; resolution set

Well ... try to write something into that file, and see what is the output on the filesystem? :-D

I did, but I was using an MSYS2 shell, so my download path was a unix one (/c/Users/ and not C:\, so it was working..

r24226 was tested with a DOS path, including with the filenames you provided. Closing at last.


Mon, 21 Oct 2019 20:01:26 GMT - stdedos:

Also verified myself with https://xpra.org/beta/windows/Xpra-Python2-x86_64_3.0.1-r24232.zip


Sat, 23 Jan 2021 05:51:45 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2456