Activity for xfe
-
Roland Baudin modified ticket #314
Crash when manipulating bookmarks
-
File move/copy very slow in 2.1.5
-
Hi, I released today the new Xfe 2.1.6, with the bug fixed. Thanks to all of you!
-
xfe released /xfe/2.1.6/xfe-2.1.6.tar.xz
-
-
-
-
-
Thanks for the report. I fixed the issue. I'll test more carefully today and tomorrow you'll get a new release.
-
Nissan Fan posted a comment on ticket #315
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,...
-
Exactly! I just saw the same behaviour 15 seconds before your message. So now it's reproducible, at last...
-
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 ??!!
-
Thanks!
-
Jerry Lovejoy posted a comment on ticket #315
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 for the report. Since I can't reproduce the issue, I need more information: which Xfe 2.1.5 package did you use? (the one I provide, the one provided by Ubuntu or did you compile it?) what hardware do you have (processor, hard drive)?
-
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.
-
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.
-
Yeah, I'll test with that. Thanks.
-
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 ?
-
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...
-
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 :-)
-
Maybe it's the return of the infamous Tuesday bug ;-) https://www.youtube.com/watch?v=-6fPfwixNLk
-
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?
-
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);
-
beastie posted a comment on ticket #314
I think you can close this one. Thanks again.
-
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?
-
Is your system running in a VM or not?
-
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...
-
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...
-
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.
-
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.
-
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...
-
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),...
-
Thanks! I see nothing weird in your Xfe profile...
-
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.
-
Here attached my xferc file. This slow file copy issue was also reported by another user one 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.
-
Could you post your Xfe profile? Thanks.
-
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?
-
File move/copy very slow in 2.1.5
-
It works like a charm. Thank you.
-
вдмЪ modified a comment on ticket #314
FreeBSD 15 I had the same problem. Now, after updating to v. 2.1.5, everything works without errors. Thank you.
-
Freebsd 15 I had the same problem. Now, after updating to v. 2.1.5, everything works without errors. Thank you.
-
Fine, thanks!
-
Mamoru TASAKA posted a comment on ticket #314
For me the problem seems fixed with 2.1.5, thank you.
-
I fixed the bug in the new 2.1.5 version. Could you test it please in FreeBSD?
-
OK, thanks. I released today a new version (2.1.5) with the bug fixed. Could you test it please?
-
-
-
-
-
Now I tried Fedora 43 (LXDE) and yes, this crash is reproducible on Fedora 43.
-
At point 3.1, a dialog is open and you have to click (not double click) to select the file you want to symlink. Then click on Accept and you'll get your symlink. Yes, like point 3.3. But is there a reason for disabling double-clicking in this particular file selection dialog box? Double-clicking works fine for selecting files in: Filter > Select Destination Add Bookmark > Select Icon etc.
-
At point 3.1, a dialog is open and you have to click (not double click) to select the file you want to symlink. Then click on Accept and you'll get your symlink. Yes, like point 3.3. But is there a reason for disabling double-clicking in this particular file selection dialog box? Double-clicking works fine for selecting files in Filter > Select Destination Add Bookmark > Select Icon etc.
-
I tried to download Fedora 44, but the current version is 43. Does the crash happen in 43 too?
-
At point 3.1, a dialog is open and you have to click (not double click) to select the file you want to symlink. Then click on Accept and you'll get your symlink. But indeed, there is a bug: pressing enter in the dialog when a file is selected should close the dialog.
-
I tried 1. i.e. but if you try adding another one Xfe crashes. and crash is reproducible, on Fedora 44: /usr/include/c++/16/bits/stl_vector.h:1253: constexpr std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = FX::FXMenuCommand*; _Alloc = std::allocator<FX::FXMenuCommand*>; reference = FX::FXMenuCommand*&; size_type = long unsigned int]: Assertion '__n < this->size()' failed. Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=<optimized...
-
FreeBSD 14.3, official package (https://cgit.freebsd.org/ports/tree/x11-fm/xfe/Makefile).
-
I don't understand. Isn't this supposed to do the same thing ln(1) does on the command-line, or am I expecting something that isn't there? Right-click > New File > "text.txt" > Accept Right-click > New Symlink > "link" > Accept 3.1. Double-click on "text.txt" -> nothing 3.2. Press "Enter" -> nothing 3.3. Click "Ok" -> a symbolic link called "link" is successfully created
-
Yes it works. But maybe you tested with a file that is associated with a program that does not exist. Ex: if pdf files are associated to atril and atril does not exist, then a dialog is open to let you choose a program. I realize I could improve this by informing the user that the associated program does not exist.
-
Thanks. I can't reproduce the bug. Could you give me more details: what is your system? Did you compile Xfe by yourself? Did you use some custom option when compiling?
-
Crash when manipulating bookmarks
-
This still doesn't work in Xfe 2.1.4. Can you confirm?
-
-
-
-
-
Use-after-free when xfi goes to invalid image file then trying to redraw it
-
The issue is fixed in the new Xfe 2.1.3. I rewrote some part of the XFileImage code. Thanks for your help in solving this issue.
-
-
-
-
-
No problem, I clicked the left arrow from the beginning. But thanks for the clarification.
-
on xfi window, click right arrow button (click "Previous" button) Oh, this is on xfi window, click left arrow button (click "Previous" button), then perhaps popup window with "Unsupported type: txt" appears, sorry...
-
OK, thanks for the tip! I tried with valgrind but I saw no error when doing the steps from your bug report. Then I compiled with your recommended flags and saw no error: g++ -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../intl -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -O2 -Wall -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr -I/usr/include/fox-1.6...
-
OK, thanks for the tip! I tried with valgrind but I saw no error when doing the steps from your bug report. Then I compiled with your recommended flags and saw no error: g++ -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../intl -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -O2 -Wall -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr -I/usr/include/fox-1.6...
-
OK, thanks for the tip! I tried with valgrind but I saw no error when doing the steps from your bug report. Then I compiled with your recommended flags and saw no error: g++ -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../intl -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -O2 -Wall -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr -I/usr/include/fox-1.6...
-
Perhaps recompiling xfe and fox with sanitizer , e.g. export CC="gcc -fsanitize=address -fsanitize=undefined" export CXX="g++ -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr" or using valgrind makes this issue easier to reproduce.
-
Hi, thanks for he bug report. However, I was unable to reproduce the crash in Ubuntu. I'll investigate further...
-
Tentative workaround: diff --git a/src/XFileImage.cpp b/src/XFileImage.cpp index f5beb1d..14faf4b 100644 --- a/src/XFileImage.cpp +++ b/src/XFileImage.cpp @@ -1618,6 +1618,10 @@ FXbool XFileImage::loadimage(const FXString& file) FILE* fp = fopen(file.text(), "r"); + // Save old image + FXImage *img_old = img; + FXImage *tmpimg_old = tmpimg; + if (!fp) { MessageBox::error(this, BOX_OK, _("Error"), _("Unable to open file: %s"), file.text()); @@ -1628,18 +1632,6 @@ FXbool XFileImage::loadimage(const...
-
Use-after-free when xfi goes to invalid image file then trying to redraw it
-
Thanks! Happy new to you and your family!
-
Hartmut Bromkamp posted a comment on ticket #311
Hi, Roland, Thanks, got some notice a few hours ago that you've worked on the source code. Great news! Ah, happy new year, mate! All the best for 2026! I'm away from my network system but will do tests as soon as I'm at home again, maybe in one or two weeks. Take care Hartmut
-
[FTBS] xfe v2.0.1 on openSUSE Leap 15.6
-
Shell window runs when starting Xfe
-
[Xfe] Window width fixed at 652px
-
I could allow a smaller window size, but this has some (bad) side effects on the toolbar placement so I prefer not changing anything...
-
Removing a Bookmark
-
[Xfe] New Symlink fixes
-
Fixed in Xfe 2.1.2.
-
Bookmarks get lost with every reboot
-
Fixed in Xfe 2.1.2.
-
xfe [FOLDER] is not working
-
Fixed in Xfe 2.1.2.
-
[Xfe] File list order is not honored
-
Fixed in Xfe 2.1.2.
-
Ampersand sign in bookmarks
-
Fixed in Xfe 2.1.2.
-
[Xfe] Keyboard cursor invisible in the Search window
-
Fixed in Xfe 2.1.2.
1 >
