xpra icon
Bug tracker and wiki

Opened 4 weeks ago

Closed 4 weeks ago

Last modified 4 weeks ago

#2456 closed defect (fixed)

xpra start handle name normalization

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 4.0
Component: client Version: 3.0.x
Keywords: Cc:

Description

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'

Change History (9)

comment:1 Changed 4 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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?

comment:2 Changed 4 weeks ago by stdedos

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

comment:3 Changed 4 weeks ago by stdedos

Oh, oh, apologies! 😁

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

comment:4 Changed 4 weeks ago by totaamwin32

Owner: changed from stdedos to totaamwin32
Status: newassigned

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!

comment:5 Changed 4 weeks ago by 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?

comment:6 Changed 4 weeks ago by totaamwin32

Owner: changed from totaamwin32 to stdedos
Status: assignednew

Should be fixed in r24216.

Please try the latest beta win32 build.

comment:7 in reply to:  5 Changed 4 weeks ago by 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))

Last edited 4 weeks ago by stdedos (previous) (diff)

comment:8 Changed 4 weeks ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.