Xpra: Ticket #2671: xdg-open download file fails

I cannot download the following file:

~/aaaaaaaaa/aaaaaaaaaa/aaa/aaaaaaaaa aaaaaa aaaaaaaaa.md (with and without the spaces in-path)

I've tried it multiple times, with no output what-so-ever.

The file downloaded is empty, even though it's detected properly (6.3kb):

23/03/2020  04:33 μμ                 0 aaaaaaaaa aaaaaa aaaaaaaaa.md

It also seems that xpra holds the file handle for the file it fails to download for ever.


Once, I found the following output:

client:

2020-03-23 16:33:32,537 unknown string message: 0xc297 / 0x0 / 0x0
2020-03-23 16:33:40,144 Error: chunked file transfer timed out

server:

 293   │ 2020-03-23 16:33:30,560 Error: cannot find the file transfer id '0fba2d456f3a4af0bbc092a52fea6b3e'


Mon, 23 Mar 2020 14:46:02 GMT - stdedos: attachment set


Mon, 23 Mar 2020 15:15:15 GMT - stdedos:

File ~/aaaaaaaaa/aaaaaaaaaa/aaa/redact-xpra-2604-200-1.log can be downloaded normally (same directory), idk what's the deal with my original file.

They have the same access rights (0664/-rw-rw-r--)


Mon, 23 Mar 2020 17:13:14 GMT - Antoine Martin: owner changed

Can you attach the problematic file? Or one that triggers the problem? (same size? same header? same content-type?)

And post the server log, running both the client and server with -d file.

I've just tried it and the file was not locked.

It could just be a fluke. Maybe we're losing track of transfers somehow and it eventually times out. But your file is tiny, so it should fit in a single chunk - which is even easier to handle.


Wed, 25 Mar 2020 10:07:03 GMT - stdedos:

Replying to Antoine Martin:

Can you attach the problematic file? Or one that triggers the problem? (same size? same header? same content-type?)

And post the server log, running both the client and server with -d file.

I've just tried it and the file was not locked.

It could just be a fluke. Maybe we're losing track of transfers somehow and it eventually times out. But your file is tiny, so it should fit in a single chunk - which is even easier to handle.

It seems "random": File redact-xpra-sidekick-2640-all.log can be downloaded:

$ stat redact-xpra-sidekick-2640-all.log
  File: 'redact-xpra-sidekick-2640-all.log'
  Size: 173084    	Blocks: 360        IO Block: 4096   regular file
Device: 35h/53d	Inode: 30411749    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/user.ix)   Gid: ( 1000/user.ix)
Access: 2020-03-25 11:56:51.046512149 +0200
Modify: 2020-03-25 11:56:51.042512119 +0200
Change: 2020-03-25 11:56:51.042512119 +0200
 Birth: -
$ file redact-xpra-sidekick-*
redact-xpra-sidekick-2640-all.log:    ASCII text, with very long lines
redact-xpra-sidekick-2640-opengl.log: ASCII text
$

But file redact-xpra-sidekick-2640-opengl.log cannot:

$ cat !$
cat ~/redact-xpra-sidekick-2640-opengl.log
2020-03-25 10:26:32,266 Xpra GTK3 X11 client version 3.0.8-r25747 64-bit
2020-03-25 10:26:32,329  running on Linux Ubuntu 16.04 xenial
2020-03-25 10:26:32,330  window manager is 'Xpra'
2020-03-25 10:26:32,362 Warning: failed to query pulseaudio using 'pactl info'
2020-03-25 10:26:32,362  Connection failure: Connection refused
2020-03-25 10:26:32,362  pa_context_connect() failed: Connection refused
2020-03-25 10:26:32,398 init_opengl(probe)
2020-03-25 10:26:32,398 init_opengl: enable_option=probe
2020-03-25 10:26:32,398 checking with <function OpenGL_safety_check at 0x7f76c6229f28>
2020-03-25 10:26:32,399 <function OpenGL_safety_check at 0x7f76c6229f28>()=None
2020-03-25 10:26:32,399 checking with <function gl_check at 0x7f76b838f048>
2020-03-25 10:26:32,399 <function gl_check at 0x7f76b838f048>()=None
2020-03-25 10:26:32,399 init_opengl: going to import xpra.client.gl
2020-03-25 10:26:32,399 init_opengl: backend options: ('native',)
2020-03-25 10:26:32,399 attempting to load 'native' OpenGL backend
2020-03-25 10:26:32,399 importing xpra.client.gl.gtk3.nativegl_client_window
2020-03-25 10:26:32,422 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'
2020-03-25 10:26:32,526 xpra.client.gl.gtk3.nativegl_client_window=<module 'xpra.client.gl.gtk3.nativegl_client_window' from '/usr/lib/python3/dist-packages/xpra/client/gl/gtk3/nativegl_client_window.py'>
2020-03-25 10:26:32,534 found GLX version 1.4
(xpra:17842): Gdk-ERROR **: The program 'xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 231 error_code 2 request_code 151 (GLX) minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
$ stat ~/redact-xpra-sidekick-2640-opengl.log
  File: 'redact-xpra-sidekick-2640-opengl.log'
  Size: 2064      	Blocks: 24         IO Block: 4096   regular file
Device: 35h/53d	Inode: 30411846    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/user.ix)   Gid: ( 1000/user.ix)
Access: 2020-03-25 11:56:51.058512237 +0200
Modify: 2020-03-25 11:56:51.054512207 +0200
Change: 2020-03-25 11:56:51.054512207 +0200
 Birth: -

Wed, 25 Mar 2020 16:00:51 GMT - Antoine Martin:

The crash from comment:3 is an opengl crash, nothing to do with downloads AFAICT.


Wed, 25 Mar 2020 16:10:34 GMT - stdedos:

This is the file that failed to download. (as it may be obvious, I should/will upload that to #2640)

The file contents (ie the opengl core) are not of this ticket's concern


Wed, 25 Mar 2020 16:14:42 GMT - Antoine Martin:

This is the file that failed to download. (as it may be obvious, I should/will upload that to #2640)

I saved it to a text file and downloaded it without problems...


Wed, 25 Mar 2020 16:16:45 GMT - stdedos:

Yeah, I guess, it makes no sense. But it does happen.


Fri, 27 Mar 2020 05:54:13 GMT - Antoine Martin: owner, status, milestone changed


Mon, 30 Mar 2020 08:42:40 GMT - stdedos:

I cannot append the timestamp just before I start the transfer to prove it, but it happens instantaneously.

$ stat !$
stat ~/out.txt
  File: '/home/user.ix/out.txt'
  Size: 5173      	Blocks: 32         IO Block: 4096   regular file
Device: 35h/53d	Inode: 30410946    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/user.ix)   Gid: ( 1000/user.ix)
Access: 2020-03-30 11:32:26.102253548 +0300
Modify: 2020-03-30 11:32:18.510197083 +0300
Change: 2020-03-30 11:32:18.510197083 +0300
 Birth: -
3968   │ 2020-03-30 11:17:47,694 client  32 @14.351 Warning: static gravity is not handled
3969   │ 2020-03-30 11:32:26,105 New unix-domain connection received
3970   │ 2020-03-30 11:32:26,105  on '/run/user/1000/xpra//user.ix-precision-t3620-20'
3971   │ 2020-03-30 11:32:28,049 Error: cannot find the file transfer id '08ad32d86b2a49a985b4d958b63191a1'
3972   │ 2020-03-30 11:32:38,052 client  32 @04.714 Error: chunked file transfer timed out
3973   │ 2020-03-30 11:32:39,054 client  32 @05.722 unknown string message: 0xc2b9 / 0x0 / 0x0
3974   │ 2020-03-30 11:34:42,218 New unix-domain connection received
3975   │ 2020-03-30 11:34:42,218  on '/run/user/1000/xpra//user.ix-precision-t3620-20'
3976   │ 2020-03-30 11:34:43,344 Error: cannot find the file transfer id '08ad32d86b2a49a985b4d958b63191a1'
3977   │ 2020-03-30 11:34:53,364 client  32 @20.017 Error: chunked file transfer timed out
3978   │ 2020-03-30 11:35:06,158 New unix-domain connection received
3979   │ 2020-03-30 11:35:06,158  on '/run/user/1000/xpra//user.ix-precision-t3620-20'
3980   │ 2020-03-30 11:35:07,516 Error: cannot find the file transfer id '08ad32d86b2a49a985b4d958b63191a1'
3981   │ 2020-03-30 11:35:17,523 client  32 @44.188 Error: chunked file transfer timed out
3982   │ 2020-03-30 11:35:17,972 New unix-domain connection received
3983   │ 2020-03-30 11:35:17,972  on '/run/user/1000/xpra//user.ix-precision-t3620-20'
3984   │ 2020-03-30 11:35:19,227 Error: cannot find the file transfer id '08ad32d86b2a49a985b4d958b63191a1'
3985   │ 2020-03-30 11:35:29,228 client  32 @55.905 Error: chunked file transfer timed out

Sat, 16 May 2020 12:40:28 GMT - stdedos:

Would that be the fix? r26358

If yes, would you put a beta build in the pipeline sometime for next week?


Sat, 16 May 2020 12:57:53 GMT - Antoine Martin:

Would that be the fix? r26358

No.

I am still unable to reproduce your problem.


Sat, 16 May 2020 13:01:08 GMT - stdedos:

I guessed that, but that's all the diagnostic xpra spews anyway.

Any -d file with server/client:

sending/receiving file %abs_path%, stat: %stat%, size: %size%
up/downloading: %percent %%
sent/received file %abs_path%, size: %size%

or anything else that you think it might help?


Tue, 19 May 2020 12:48:10 GMT - stdedos:

filename is visible, I just scrubbed too much

Canceling

2020-05-19 15:44:14,840 Error: chunked file transfer timed out
2020-05-19 15:48:51,490 Error: cannot cancel download 7d872178d4e74691b34736eb4a3f478e, entry not found!

does not seem to release the file hand on the file either.

I ran:

u@h:~/a/b/c$ xdg-open /home/u/d/e/f/file.csv

... and I am 3/3 replicated this issue


Tue, 19 May 2020 12:48:30 GMT - stdedos: attachment set


Mon, 01 Jun 2020 11:05:36 GMT - stdedos:

File is downloaded, but the progress bar does not appear complete.


Mon, 01 Jun 2020 11:05:58 GMT - stdedos: attachment set


Mon, 01 Jun 2020 11:07:12 GMT - stdedos:

File in attachment/ticket/2792/redact-display-_0-%24TIMESTAMP.log


Mon, 01 Jun 2020 14:44:56 GMT - Antoine Martin: owner, status changed

File is downloaded, but the progress bar does not appear complete.

Is this reproducible reliably? Do you have the -d file output?


Mon, 01 Jun 2020 18:12:56 GMT - stdedos:

As all the file issues - no. It is reproducible intermittently.

I'll try to have -d file active-by-default, hopefully I'll scoop up something ...


Mon, 14 Sep 2020 13:19:39 GMT - stdedos:

New Data: raw-attachment/ticket/2671/2020-09-14_15-33-55.mp4​

Video is self-explanatory. I xdg-open a file, I start the transfer, re-do xdg-open again.

After that, I downloaded a ~200kb file just fine.

If all the files would be <4KB, and chunks would be <4KB also, I'd say that somehow it does not like one-chunk files, but it works with larger ones.

Attaching log with xpra control :3 debug enable file, xpra control :3 client debug enable file:

2020-09-14 16:09:07,769 enabled debugging for:
2020-09-14 16:09:07,777  - Logger(xpra.net.file_transfer, file)
2020-09-14 16:09:07,781  - Logger(xpra.client.mixins.fileprint_mixin, file)
2020-09-14 16:09:07,789  - Logger(xpra.client.gtk_base.open_requests, gtk, file)
2020-09-14 16:09:07,794  - Logger(xpra.client.gtk_base.gtk_client_base, gtk, client, file)
2020-09-14 16:09:16,925 process send-data-request: send_id=b'a958da71badc42ad8552e00b20aff9ec', url=b'/home/sntentos/Documents/Forcepoint/atf/etc/elements/sgfw/testplans/vpn_client/certificate_authentication/f.xml', printit=False, openit=True
2020-09-14 16:09:17,024 show()
2020-09-14 16:09:19,968 accept(b'f.xml', False, True)=1
2020-09-14 16:09:20,003 receiving file: [b'f.xml', b'', False, True, 5670, '5670 bytes', {b'sha1': b'bfcf29c869ea64873fe90d9163d0901c0c021182', b'file-chunk-id': b'aa6d3a870057420cbe1f854691e56f89'}]
2020-09-14 16:09:20,008 cannot save file as %home%\Downloads\f.xml: file already exists
2020-09-14 16:09:20,010 cannot save file as %home%\Downloads\f-1.xml: file already exists2020-09-14 16:09:20,012 cannot save file as %home%\Downloads\f-2.xml: file already exists2020-09-14 16:09:20,014 cannot save file as %home%\Downloads\f-3.xml: file already exists2020-09-14 16:09:20,016 cannot save file as %home%\Downloads\f-4.xml: file already exists2020-09-14 16:09:20,019 cannot save file as %home%\Downloads\f-5.xml: file already exists2020-09-14 16:09:20,021 cannot save file as %home%\Downloads\f-6.xml: file already exists2020-09-14 16:09:20,023 cannot save file as %home%\Downloads\f-7.xml: file already exists2020-09-14 16:09:20,024 cannot save file as %home%\Downloads\f-8.xml: file already exists2020-09-14 16:09:20,029 cannot save file as %home%\Downloads\f-9.xml: file already exists2020-09-14 16:09:20,032 cannot save file as %home%\Downloads\f-10.xml: file already exists
2020-09-14 16:09:20,033 cannot save file as %home%\Downloads\f-11.xml: file already exists
2020-09-14 16:09:20,035 cannot save file as %home%\Downloads\f-12.xml: file already exists
2020-09-14 16:09:20,037 cannot save file as %home%\Downloads\f-13.xml: file already exists
2020-09-14 16:09:20,038 cannot save file as %home%\Downloads\f-14.xml: file already exists
2020-09-14 16:09:20,043 cannot save file as %home%\Downloads\f-15.xml: file already exists
2020-09-14 16:09:20,045 cannot save file as %home%\Downloads\f-16.xml: file already exists
2020-09-14 16:09:20,046 safe_open_download_file(f.xml, b'') will use '%home%\Downloads\f-17.xml'
2020-09-14 16:09:20,049 using filename '%home%\Downloads\f-17.xml', file descriptor=35
2020-09-14 16:09:30,053 _check_chunk_receiving(b'aa6d3a870057420cbe1f854691e56f89', 0) chunk_state=[281374.62742644554, 35, '%home%\\Downloads\\f-17.xml', b'', False, True, 5670, {b'sha1': b'bfcf29c869ea64873fe90d9163d0901c0c021182', b'file-chunk-id': b'aa6d3a870057420cbe1f854691e56f89'}, <sha1 HASH object @ 0x0000000000b6b8f0>, 0, False, b'a958da71badc42ad8552e00b20aff9ec', 958314, 0]
2020-09-14 16:09:30,057 Error: chunked file transfer timed out
2020-09-14 16:09:40,324 disabled debugging for:
2020-09-14 16:09:40,328  - Logger(xpra.net.file_transfer, file)
2020-09-14 16:09:40,329  - Logger(xpra.client.mixins.fileprint_mixin, file)
2020-09-14 16:09:40,331  - Logger(xpra.client.gtk_base.open_requests, gtk, file)
2020-09-14 16:09:40,332  - Logger(xpra.client.gtk_base.gtk_client_base, gtk, client, file)

FYI, server log has some more bugs, including logging issues. I know you are fund-less, but, if you are interested ...


Mon, 14 Sep 2020 13:23:52 GMT - stdedos: attachment set


Mon, 14 Sep 2020 13:24:12 GMT - stdedos: attachment set


Mon, 14 Sep 2020 13:24:26 GMT - stdedos: attachment set


Mon, 14 Sep 2020 13:24:37 GMT - stdedos: attachment set


Tue, 15 Sep 2020 12:03:44 GMT - Antoine Martin: owner, status changed

I can reproduce, and more: the "Download" link does "Download and Open" when it should not.


Tue, 15 Sep 2020 12:07:42 GMT - stdedos:

Replying to Antoine Martin:

I can reproduce, and more: the "Download" link does "Download and Open" when it should not.

Dat too


Tue, 15 Sep 2020 12:52:25 GMT - Antoine Martin: status changed; resolution set


Wed, 16 Sep 2020 08:08:44 GMT - stdedos:

Not fixed:

"Xpra-Python3-x86_64_4.1-r27467M\xpra_cmd" attach ssh://user@ip/3 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @@/@server-display@" --headerbar=off --opengl=no --bandwidth-limit=6Mbps
2020-09-16 10:56:46,597 Xpra GTK3 client version 4.1-r27467M 64-bit
2020-09-16 10:56:46,600  running on Microsoft Windows 10
2020-09-16 10:56:49,261 GStreamer version 1.18.0 for Python 3.8.5 64-bit
2020-09-16 10:56:49,609 created named pipe '\\.\pipe\Xpra\4288'
2020-09-16 10:56:49,918 keyboard layout code 0x409
2020-09-16 10:56:49,919 identified as 'United States - English' : us
2020-09-16 10:56:50,312  keyboard settings: layout=us
2020-09-16 10:56:50,325  desktop size is 4160x1440 with 1 screen:
2020-09-16 10:56:50,325   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-09-16 10:56:50,325     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860 at 0x534
2020-09-16 10:56:50,326     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400 at 1600x0
2020-09-16 10:56:54,535 enabled remote logging
2020-09-16 10:56:54,539 Xpra GTK3 X11 server version 3.0.10-r26630 64-bit
2020-09-16 10:56:54,540  running on Linux Ubuntu 16.04 xenial
2020-09-16 10:56:54,554 Attached to ip:22
2020-09-16 10:56:54,555  (press Control-C to detach)
(xpra_cmd:4288): Pango-WARNING **: 10:56:55.394: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output.
2020-09-16 10:56:56,278 sound output using 'opus' audio codec
2020-09-16 10:56:56,432 UI thread is now blocked
2020-09-16 10:56:56,894 UI thread is running again, resuming
Traceback (most recent call last):
  File "E:\Xpra\trunk\src/xpra/client/gtk_base/gtk_tray_menu_base.py", line 645, in show_shortcuts
  File "E:\Xpra\trunk\src/xpra/client/gtk_base/gtk_client_base.py", line 549, in show_shortcuts
ModuleNotFoundError: No module named 'xpra.client.gtk3.show_shortcuts'
2020-09-16 11:05:17,224 Error: chunked file transfer timed out
2020-09-16 11:05:28,537 Error: chunked file transfer timed out
2020-09-16 11:05:30,890 downloaded 133452 bytes to temporary file:
2020-09-16 11:05:30,893  '%home%\Downloads\.patch'
2020-09-16 11:05:35,505 unknown string message: 0xc238 / 0x0 / 0x0
2020-09-16 11:05:40,811 Error: chunked file transfer timed out
2020-09-16 11:05:53,138 UI thread is now blocked
2020-09-16 11:05:53,301 UI thread is running again, resuming

Also: Weird build ID: r27467M Also also: Missing signature/md5/sha1 metafiles


Wed, 16 Sep 2020 08:52:45 GMT - Antoine Martin:

Not fixed: (..) Error: chunked file transfer timed out

This looks like a different issue as more than one chunk is used. Is this reproducible? Do you have the -d file output?


I tested:

The log shows:

233 process send-data-request: send_id=b'04540ae0747f4324952e5f3c9bac91b2', url=b'/home/antoine/test-file-transfer', printit=False, openit=True
237 show()
267 accept(b'test-file-transfer', False, True)=1
270 receiving file: [b'test-file-transfer', b'', False, False, 133452, '0 bytes', {b'sha1': b'c9bce29d3d51ec4fea1cdeb6687f558d8c7fc7f8', b'file-chunk-id': b'6a4afac8ae544a238e4eff21f5eef9a1'}]
271 cannot save file as C:/Users/Windows 10 Test/Downloads/test-file-transfer: file already exists
271 safe_open_download_file(test-file-transfer, b'') will use 'C:/Users/Windows 10 Test/Downloads/test-file-transfer-1'
272 using filename 'C:/Users/Windows 10 Test/Downloads/test-file-transfer-1', file descriptor=3
292 _process_send_file_chunk(b'6a4afac8ae544a238e4eff21f5eef9a1', 1, '65536 bytes', True)
293 transfer_progress_update(False, b'04540ae0747f4324952e5f3c9bac91b2', 0.020264599999791244, 65536, 133452, None) pb=<Gtk.ProgressBar object at 0x0000000037e08e00 (GtkProgressBar at 0x00000000039d5c10)>
313 _process_send_file_chunk(b'6a4afac8ae544a238e4eff21f5eef9a1', 2, '65536 bytes', True)
314 transfer_progress_update(False, b'04540ae0747f4324952e5f3c9bac91b2', 0.041378800000529736, 131072, 133452, None) pb=<Gtk.ProgressBar object at 0x0000000037e08e00 (GtkProgressBar at 0x00000000039d5c10)>
317 _process_send_file_chunk(b'6a4afac8ae544a238e4eff21f5eef9a1', 3, '2380 bytes', False)
331 133452 bytes received in 3 chunks, took 58ms
332 transfer_progress_update(False, b'04540ae0747f4324952e5f3c9bac91b2', 0.05861169999843696, 133452, 133452, None) pb=<Gtk.ProgressBar object at 0x0000000037e08e00 (GtkProgressBar at 0x00000000039d5c10)>
335 do_process_downloaded_file('C:/Users/Windows 10 Test/Downloads/test-file-transfer-1', '', False, False, 133452, {b'sha1': b'c9bce29d3d51ec4fea1cdeb6687f558d8c7fc7f8', b'file-chunk-id': b'6a4afac8ae544a238e4eff21f5eef9a1'})
337 downloaded 133452 bytes to temporary file:
339  'C:/Users/Windows 10 Test/Downloads/test-file-transfer-1'
2020-09-16 15:49:03,440 client   7 @28.340 close()
2020-09-16 15:49:03,442 client   7 @28.341 hide()

Wed, 16 Sep 2020 09:02:58 GMT - stdedos: attachment set


Wed, 16 Sep 2020 09:04:23 GMT - stdedos:

Do you have the -d file output?

Uploaded

(..)

I'd hate if this happened again, so: is the client Win10?


Wed, 16 Sep 2020 11:31:23 GMT - Antoine Martin:

I'd hate if this happened again, so: is the client Win10?

Yes.

Uploaded

I've tried using an Ubuntu 16.04 system as server just like you did. No dice.

How many attempts did you need to trigger the problem? Did you cancel any transfers first? Looks to me like r27476 might help, but I didn't hit any issues without...


Wed, 16 Sep 2020 12:17:13 GMT - stdedos:

Replying to Antoine Martin:

How many attempts did you need to trigger the problem? Did you cancel any transfers first?

I did the same test as shown in the comment above comment:18.

On empty list:

Repeat again with a bigger one

Looks to me like r27476 might help, but I didn't hit any issues without...

I'll keep a note to apply this too


Thu, 24 Sep 2020 11:56:48 GMT - stdedos:

At least, I can now press "Stop" and it will release/remove the file. It still won't download it though. (patch not applied)


Thu, 08 Oct 2020 08:06:17 GMT - stdedos:

Updated to 3.0.12. Now the files download.

However, I have a different problem:

When pressing "Download" at least, the window should remain open (to be able to click "Open Downloads Folder")


Thu, 08 Oct 2020 13:47:41 GMT - Antoine Martin:

In an xterm forwarded from Ubuntu Xenial to an mswindows client:

echo -n hello123 > test.txt
xdg-open test.txt

No timeout, no freezing.

If you want to change the default delay or get rid of it, please create a new ticket.


Thu, 08 Oct 2020 14:14:11 GMT - stdedos:

Replying to Antoine Martin:

In an xterm forwarded from Ubuntu Xenial to an mswindows client:

echo -n hello123 > test.txt
xdg-open test.txt

No timeout, no freezing.

If you want to change the default delay or get rid of it, please create a new ticket.

I took the "5 second delay" as "freezing", because before and after that nothing happened, and the window closed.

I thought download window was not disappearing after all the entries were removed, if one was "download"ed (and not opened), but I guess I was working quicker that time maybe.

This all sounds too complicated to put it into code; let's ignore it.


Sat, 23 Jan 2021 05:57:41 GMT - migration script:

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