Menu
▾
▴
#315 File move/copy very slow in 2.1.5
Hi,
with version 2.1.5 file operations like move or copy on large files are now very slow compared to 2.0.1 or thunar or just simple cp .
On my HDD only system it now takes about 5 minutes to copy a 2.3 GB iso file, whereas with XFE 2.0.1 or Thunar or cp only about 30 seconds are required.
I am using MX Linux 25 with the latest XFE 2.1.5 build.
Sorry, I can't reproduce the issue.
On my Ubuntu 24.04 system with an SSD drive:
(I do a clear cache before each timing: sudo sh -c "sync ; echo 3 > /proc/sys/vm/drop_caches")
Copy a 2.6 GB video file:
Xfe => 5s
Thunar => 5s
cp => 5s
Maybe a system issue? Or an Xfe build issue in your system?
Could you post your Xfe profile? Thanks.
Here attached my xferc file.
This slow file copy issue was also reported by another user on the MX forum, so rather not an individual system problem. The 2.1.5 xfe build was performed by the MX build team, so unfortunately I have no further information about build problems.
MX 25 is based on Debian 13; I also have a vanilla Debian 13 with XFE 2.0.1 installed on the same machine which isn't showing this slow copy behavior.
Last edit: Nissan Fan 4 days ago
Thanks! I see nothing weird in your Xfe profile...
Here two more comments from the MX Forum confirming the issue:
Re: Package request: xfe 2.1.5
#11 Post by timkb4cq » Sun Mar 22, 2026 3:08 pm
I purged my build of Xfe and reinstalled using the developer's xfe-2.1.5-install-linux-amd64.run file from Sourceforge.
Copies using Xfe between internal rotating drive or USB flash drive and nvme drive max out at 16.8 Mb/s
Copies using Xfe 2.1.4 and Thunar both copy at full speed.
Have him try flash drive copies.
HP Pavillion TP01, AMD Ryzen 3 5300G (quad core), Crucial 500GB SSD, Toshiba 6TB 7200rpm
Dell Inspiron 15, AMD Ryzen 7 2700u (quad core). Sabrent 500GB nvme, Seagate 1TB
Re: Package request: xfe 2.1.5
#12 Post by Kruppt » Sun Mar 22, 2026 4:05 pm
wdscharff wrote: Sun Mar 22, 2026 1:52 am
<snip></snip>
The speed of file operations (copy and move) drops to ridiculously low levels. Instead of the typical 300-500 MB/sec I usually get between my SSDs, it's only 10-20 MB/sec. An MX snapshot of ~5GB then takes almost 10 minutes instead of 10-12 seconds.
I would appreciate it if other users could either confirm that this is limited to my system or if it occurs more generally before it's moved from the testing section to the main section.
Yeah , I can confirm .. same thing here. Even when compiling it from source I am getting the same results.
Last edit: Nissan Fan 2 days ago
Here are further test results using different kernels:
#13 Post by wdscharff » Mon Mar 23, 2026 1:25 am
I've now tried several kernels: 6.18.15 and Liquorix 6.18.16 from MXPI, and 6.19.9 directly from Liquorix.
Both under sysvinit (my default) and systemd.
The results are the same everywhere. With 2.1.1, data transfer rates are between 350-600 MB/s, depending on whether it's internal or external USB, and with 2.1.5, the rate drops to 5-15 MB/s.
Measured with a 5 GB file and a directory with approximately 100 JPGs, transfer rates ranged from 2-20 MB/s.
My system specs are Fluxbox, AMD Ryzen 9 3900x, SSDs: 970 EVO Plus, 850 EVO, Samsung PSSD T7, Crucial CT2000MX500SSD1.
It also makes no difference whether I obtain the DEB directly from the XFE website or install the MX "version" from the MXPI.
On a different HDD only system with an older 5.19.0-14.1-liquorix-amd64 kernel I have similar findings, XFE 2.1.1 is copying fine, XFE 2.1.5 is slow.
Looking at the CPU utilisation during the copy process XFE 2.1.5 shows only about 8% whereas XFE 2.1.1 utilizes about 50%.
To me it seams as if the XFE 2.1.5 process is waiting for something, maybe a timeout ?
Last edit: Nissan Fan 2 days ago
Maybe it's MX Linux-specific, because I can't reproduce it here on FreeBSD.
I've tried multiple big files of 1GB, 2GB, 2.xGB each. Every GB takes consistently 20s more or less and Xfe 2.1.5 is using an average of 5% of CPU.
That's on a rather old Core i3 machine with a SATA 2.x disk.
Hi,
in the meantime I installed a fresh Xubuntu 24.04.4 system and guess what, XFE 2.1.5. copies 'very slowly' as opposed to Ubuntus repository version 1.45 which is fast as usual.
Attached you find the system info of that Xubuntu install.
I used the xfe_2.1.5-1jammy_amd64.deb package from this site to install XFE 2.1.5.
So in my opinion it's not a MX or Debian 13 issue since it can be replicated also on (X)ubuntu.
In my tests I copy a 2 GB iso file between 2 partitions on a single HDD.
Is your system running in a VM or not?
Last time I was testing it I was copying from disk to memory. Now I've tried between 2 partitions of the same disk like you did and it was just a few seconds slower than before.
Note that it is a regular disk, not even an SSD.
Could it be some kind of interference with an Xfce process?
Always just regular installs on disk, no VM. The partitions are formated as ext4.
Looking at the change log I think - copy speed is now computed as a moving average of 20 values obtained every second is interesting.
Maybe something in the method
// Refresh copy speed long File::onCopySpeed(FXObject, FXSelector, void)
There is a timeout set right at the end:
// Restart timeout
prevTotaldataread = totaldataread;
getApp()->addTimeout(this, File::ID_COPYSPEED, COPYSPEED_DELAY);
OK, thanks. This change was introduced in Xfe 2.1.4. Could you test both 2.1.3 and 2.1.4 on your system?
Maybe it's the return of the infamous Tuesday bug ;-)
https://www.youtube.com/watch?v=-6fPfwixNLk
Just tested 2.1.1 - 2.1.4 . 2.1.3 is still fast copying, with 2.1.4 the slow copy issue starts.
One of the MX users suggested to test copies between SSDs and USB flash drives if no 'old school' HDD is available, see the previous comments.
At least it shouldn't take us 4 years to figure this one out :-)
OK, thanks! Clearly the bug is related to the changes I made in 2.1.4 for computing the copy speed. The problem for me now is to reproduce the bug...
Hmm, on the Xubuntu system file copies between the HDD partition and an external USB stick ( USB 2 port ? ) also take significantly longer with XFE 2.1.4 than with 2.1.3.
Maybe that's also true if you copy from an SSD to a much slower USB connected device. Do you have an external SSD or HDD drive available, i.e. for system backups ?
I still can't reproduce the issue.
I tested with an external HDD drive, with USB 3 connection. Same copy speed for cp or Xfe 2.1.5. My system is Ubuntu 24.04.4.
Last edit: Roland Baudin 2 days ago
Same issue affecting my systems, both Kubuntu 24.04 LTS. Speed reduction copying files is dramatic - at least 90%. Had to (reluctantly) use another file manager (Krusader usually) when copying/moving files. Reinstalling 2.1.3 fixed it.
Thanks for the report. Since I can't reproduce the issue, I need more information:
The one installed by "xfe-2.1.5-install-linux-amd64.run".
One computer is AMD Ryzen 5 5500GT with 2TB NVME.
Second computer is an old Intel Core i5-3570K with 500GB 2.5" SATA SSD.
Copying has been done over various storage types - USB, SAMBA shares, local disks. Behaviour seems the same and not affected by the source/destination storage type or bus.
Thanks!
Doing more testing on 2.1.5 I see different copy speeds depending on how I perform the file copy in XFE.
I usually have 2 panes open and after a right click on the file to copy I chose the 'copy to' option -> this is very slow in 2.15 .
But if I chose 'copy' in pane 1 and then 'paste' in pane 2 the copy process is almost as fast as thunar or cp ??!!
Exactly! I just saw the same behaviour 15 seconds before your message. So now it's reproducible, at last...
and there is also another twist to it, just reported on the MX Forum:
Re: Package request: xfe 2.1.5
#17 Post by wdscharff » Thu Mar 26, 2026 1:19 am
a. The workaround works, I can live with that.
However, if I select "Copy" in area 1 and then "Paste" in area 2, the copying process is almost as fast as ..(before).
b. If you perform the first copy operation using copy/paste (as described in the workaround), copying with drag & drop and F5 works again AFTERWARDS, as long as the XFE is open.
Interesting, strange, that's all I can think of.