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'
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--
)
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.
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: -
The crash from comment:3 is an opengl crash, nothing to do with downloads AFAICT.
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
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...
Yeah, I guess, it makes no sense. But it does happen.
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
Would that be the fix? r26358
If yes, would you put a beta build in the pipeline sometime for next week?
Would that be the fix? r26358
No.
I am still unable to reproduce your problem.
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?
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
File is downloaded, but the progress bar does not appear complete.
File in attachment/ticket/2792/redact-display-_0-%24TIMESTAMP.log
File is downloaded, but the progress bar does not appear complete.
Is this reproducible reliably?
Do you have the -d file
output?
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 ...
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 ...
I can reproduce, and more: the "Download" link does "Download and Open" when it should not.
Replying to Antoine Martin:
I can reproduce, and more: the "Download" link does "Download and Open" when it should not.
Dat too
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
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:
xdg-open
Download
(not open) in the GUI that shows up on the client
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()
Do you have the
-d file
output?
Uploaded
(..)
I'd hate if this happened again, so: is the client Win10?
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...
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:
xdg-open
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
At least, I can now press "Stop" and it will release/remove the file. It still won't download it though. (patch not applied)
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")
In an xterm forwarded from Ubuntu Xenial to an mswindows client:
echo -n hello123 > test.txt xdg-open test.txt
XPRA_FILE_REMOVE_ENTRY_DELAY=10
(in seconds)
No timeout, no freezing.
If you want to change the default delay or get rid of it, please create a new ticket.
Replying to Antoine Martin:
In an xterm forwarded from Ubuntu Xenial to an mswindows client:
echo -n hello123 > test.txt xdg-open test.txt
- request window shows up
- accept the download
- progress bar finishes
- after 5 seconds the download window disappears - as of r27636, this delay is now configurable:
XPRA_FILE_REMOVE_ENTRY_DELAY=10
(in seconds)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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2671