Xfce Xfce 4.20 - slower file copy?

T

tingo

After I upgraded to Xfce 4.20 I have noticed two things about file copying (with Thunar):
1) the progress dialog now lists "Queued" a lot (this never showed in Xfce 4.18 and previous versions)
2) sometimes the copy process takes a lot more time than in previous versions (like 10 minutes instead of 1 - 2 minutes). Note: this is copying to a mount point which is mounted via sshfs - but that was the same in previous version too.

Has anyone else seen this?
This on
Code: 
tingo@kg-core2:~ $ freebsd-version -ku
13.4-RELEASE-p1
13.4-RELEASE-p2
relevant packages
Code: 
tingo@kg-core2:~ $ pkg info xfce thunar \*sshfs\*
xfce-4.20
thunar-4.20.1
fusefs-sshfs-3.7.3_2
 
point 2 - further checking shows that I get "Operation timed out" if I use cp to copy instead of Thunar, so the culprit here is most likely sshfs, not Thunar.
 
point 1 - this is the dialog I'm talking about
Thunar_file_progress_queued_Screenshot_2025-01-26_18-12-50.png
 
tingo said:
point 2 - further checking shows that I get "Operation timed out" if I use cp to copy instead of Thunar, so the culprit here is most likely sshfs, not Thunar.
Click to expand...

I would instantly stop using a file copy program that swallows up such an error message.
 
Weird, with 4.20 they stated to have improved the Thunar performances... 🤷‍♂️

Performance​


In the past, you might have faced situation involving bigger numbers of files in which thunar showed a freeze. Due to various different performance measures, thunar now is much more bullet-proof for action involving huge numbers of files.

This was achieved by using appropriate container types, moving some actions into separate jobs and throttling of view-updates.

A number of integration test cases will be used in order to keep performance on the current level in the future.
Click to expand...

File Transfer​


For file validation in thunar 4.18.x a md5 checksum was calculated for source and target file. This calculation turned out to be rather slow and actually superfluous. Now files are just compared directly. In addition, the usage of direct I/O operations now attempts to prevent comparison of possibly cached buffers.

An option was added to only copy files in parallel if the relevant devices are in idle state. This prevents possible fragmentation during copy for HDD drives.

Transferring files no longer steals the current focus.
Click to expand...

 
tingo said:
so the culprit here is most likely sshfs
Click to expand...
You have adjusted your settings for the ssh 'bug' that slowed everything down?

ObscureKeystrokeTiming "no"

M

Solved Post in thread 'ssh X11 forwarding is extremely slow from bhyve guest'

in your $HOME/.ssh/config, have you tried adding the following (add to each host section or as a global host * at the top)
ObscureKeystrokeTiming "no"

OpenSSH added that to add security, the default is "yes". It adds random delay to keystrokes. I found it slowed the initial ssh in and then any X apps would take minutes to open.
  • Thanks
  • Like

That directory looks wrong. It is /etc/ssh/ssh_config for client and /etc/ssh/sshd_config for the server.
 
You must log in or register to reply here.
Back
Top