[Bug] muCommander fails to open folders with a lot of .rar files.

[ErikG-GH]

Is there an existing issue for this?

• I have searched the existing issues (including the closed ones)

Description

When I try to open folder that contains many rar files (>100, >200?) muCommander shows a spinning blue wheel but does nothing further. Previously I was on version 1.3.0 of muCommander but recently I installed version 1.4.0 and the failing to open started. I just installed 1.4.1 but the problem persists.
What is also annoying is that when I go back to 1.3.0 the problem remains.
MuCommander is slow in opening folders that contain some dozens of rar files but eventually opens the folders and I can also open the rar files. Above a certain amount of rar files muCommander fails to open the folder.

Steps to reproduce

Just fill a folder with many rar files and try to open it.

Expected behavior

I expect to be able to open a folder with any amount of rar files and previously I could in version 1.3.0 before I updated.

Actual behavior

What happens is that the blue wheel keeps spinning. I can move my mouse around and click on another folder or panel but there is no execution of any command. I have to close down muCommander which is perfectly possible. I don't need to force a stop.

Screenshots?

No response

muCommander version

muCommander
Version: 1.4.1
Build date: 2024/06/12
Build number: a65fe3e

Java version

Java
Runtime version: 23-internal
VM name: OpenJDK 64-Bit Server VM
VM version: 23-internal-ahadas-0081ac197a656cdc0d88d5a5e2a0f399ee023654
VM vendor: Oracle Corporation

Operating System type and version

OS
Name: Mac OS X
Version: 13.4
Architecture: aarch64

Relevant log output

When I try to open a folder and it fails I can see the debug window but not a lot happens there and I can't copy any of it because I can't execute any command in muCommander at that moment.
I don't know where I can access a log file.

[ahadas]

@ErikG-GH the log can be found in the folder that holds the preference files

[ErikG-GH]

Here is the small portion from the latest log.
The folder /Volumes/EBooks/ebooks/ebooks newbooks/ can be loaded.
The subfolder 2024/ fails to open. In this case I only waited 4 seconds before trying to close muCommander

2024-06-17 14:51:42.663 [WT-EventQueue-0] DEBUG com.mucommander.core.LocationChanger:163 - folder=/Volumes/EBooks/ebooks/ebooks newbooks/ selectThisFileAfter=null
2024-06-17 14:51:42.665 [Thread-15] DEBUG c.m.core.BrowseLocationThread:155 - starting folder change...
2024-06-17 14:51:42.665 [Thread-15] TRACE c.m.auth.CredentialsManager:383 - returning matches=[]
2024-06-17 14:51:42.665 [Thread-15] TRACE c.m.auth.CredentialsManager:383 - returning matches=[]
2024-06-17 14:51:42.665 [Thread-15] TRACE c.m.core.BrowseLocationThread:380 - calling setCurrentFolder
2024-06-17 14:51:42.665 [Thread-15] TRACE c.m.ui.event.LocationManager:84 - calling ls() on /Volumes/EBooks/ebooks/ebooks newbooks/
2024-06-17 14:51:42.665 [Thread-15] DEBUG c.m.c.f.p.local.LocalMonitoredFile:60 - start watching /Volumes/EBooks/ebooks/ebooks newbooks/
2024-06-17 14:51:42.698 [Thread-15] DEBUG c.m.c.f.p.local.LocalMonitoredFile:77 - stop watching /Volumes/EBooks/ebooks/
2024-06-17 14:51:42.699 [Thread-15] TRACE c.m.core.LocalLocationHistory:80 - folder=file:https://localhost/Volumes/EBooks/ebooks/ebooks newbooks
2024-06-17 14:51:42.700 [Thread-15] TRACE c.m.core.LocalLocationHistory:85 - lastRecallableFolder= /Volumes/EBooks/ebooks/ebooks newbooks/
2024-06-17 14:51:42.700 [Thread-15] TRACE c.m.core.BrowseLocationThread:480 - cleaning up, folderChangedSuccessfully=true
2024-06-17 14:51:46.196 [WT-EventQueue-0] DEBUG com.mucommander.core.LocationChanger:163 - folder=/Volumes/EBooks/ebooks/ebooks newbooks/2024/ selectThisFileAfter=null
2024-06-17 14:51:46.197 [Thread-16] DEBUG c.m.core.BrowseLocationThread:155 - starting folder change...
2024-06-17 14:51:46.198 [Thread-16] TRACE c.m.auth.CredentialsManager:383 - returning matches=[]
2024-06-17 14:51:46.198 [Thread-16] TRACE c.m.auth.CredentialsManager:383 - returning matches=[]
2024-06-17 14:51:46.198 [Thread-16] TRACE c.m.core.BrowseLocationThread:380 - calling setCurrentFolder
2024-06-17 14:51:46.198 [Thread-16] TRACE c.m.ui.event.LocationManager:84 - calling ls() on /Volumes/EBooks/ebooks/ebooks newbooks/2024/
2024-06-17 14:51:46.198 [Thread-16] DEBUG c.m.c.f.p.local.LocalMonitoredFile:60 - start watching /Volumes/EBooks/ebooks/ebooks newbooks/2024/
2024-06-17 14:51:50.296 [ac-mini.local.)] DEBUG javax.jmdns.impl.DNSIncoming:210 - DNSIncoming() questions:4 answers:0 authorities:0 additionals:0
2024-06-17 14:51:50.296 [ac-mini.local.)] TRACE javax.jmdns.impl.SocketListener:53 - SocketListener(mac-mini.local.).run() JmDNS in:dns[query,fe80:0:0:0:c0c:d9e0:b6b7:3606%6:5353, length=97, id=0x0, questions=4

[ErikG-GH]

Another attempt.
I opened muCommander displaying the 'ebooks newbooks/' folder and then tried to open the subfolder '2024/' .
In the Thread-10 nothing happens anymore. I waited a couple of minutes before closing muCommander.
Here a short portion of the log:

2024-06-17 15:28:16.461 [WT-EventQueue-0] DEBUG com.mucommander.core.LocationChanger:163 - folder=/Volumes/EBooks/ebooks/ebooks newbooks/2024/ selectThisFileAfter=null
2024-06-17 15:28:16.464 [Thread-10] DEBUG c.m.core.BrowseLocationThread:155 - starting folder change...
2024-06-17 15:28:16.464 [Thread-10] TRACE c.m.auth.CredentialsManager:383 - returning matches=[]
2024-06-17 15:28:16.464 [Thread-10] TRACE c.m.auth.CredentialsManager:383 - returning matches=[]
2024-06-17 15:28:16.471 [Thread-10] TRACE c.m.core.BrowseLocationThread:380 - calling setCurrentFolder
2024-06-17 15:28:16.471 [Thread-10] TRACE c.m.ui.event.LocationManager:84 - calling ls() on /Volumes/EBooks/ebooks/ebooks newbooks/2024/
2024-06-17 15:28:16.471 [Thread-10] DEBUG c.m.c.f.p.local.LocalMonitoredFile:60 - start watching /Volumes/EBooks/ebooks/ebooks newbooks/2024/
2024-06-17 15:28:19.970 [i.local.).Timer] TRACE javax.jmdns.impl.tasks.RecordReaper:52 - RecordReaper(mac-mini.local.).run() JmDNS reaping cache
2024-06-17 15:28:19.971 [i.local.).Timer] TRACE javax.jmdns.impl.DNSCache:301 - Cached DNSEntries:

[ShayArtzi]

I've tried to reproduce this issue by creating a directory with 1,000 rar files and opening it with muC. However, in my case the directory is being listed instantaneously.

I'm attaching a zip file containing those multiple rar files (which in turn contains a plain text file). @ErikG-GH, could you please try to d/l it and open via muC on your machine to confirm if you see the issue in this case as well? thanks!

rar_dir.zip

[ErikG-GH]

Also on my machine the folder with all those very small rar files opens instantaneously. I guess the problem may not be just the number of files but also the amount of Mbytes.
I did have an issue though. When I try to open one of those tiny rar files it first asks if the rar file is password protected ( it isn't, I can open it with any rar handling app) and then I get an error display like the one I attach:

[ShayArtzi]

I was testing on a windows machine and didn't have this issue - I guess there is something going on with 7zip JNA bindings on macOS with the new builds. @ahadas FYI

[pskowronek]

FYI, checked muC v1.4.1 on macOS Ventura (intel) and all work fine with rar_dir.zip.

[ShayArtzi]

thanks @pskowronek! might be an an aarch64 issue?

[ErikG-GH]

Let me point out again that I have no problem with opening the rar_dir.zip directory. I am on Apple Silicon too.
The problem is that muCommander, when opening a directory, tries to look into rar files in that dir. Why not make it possible to turn that behaviour off? Even when muCommander worked for me it took quite some time to open a directory with about 60K of rar files, each about 1-3 KB. But eventually it did open them, now that is not the case. I just tried to go back earlier versions till 1.1.0 but the problem persisted. The finder has no problem opening these directories and I just installed OneCommander and that worked also without problems.
But, I love muCommander so much, since its origins actually.
Oh, I am still on Ventura.

[Andreas0602]

For what it's worth, I'm on macOS Sonoma with Apple silicon, and I have no performance problem with rar_dir.zip. But I do have a problem when trying to open one of those rar files.

[ErikG-GH]

That is also what I am experiencing. Only with me, after clicking cancel, I get the eroor warning about 7zip binding that I showed above.
I want to mention again that on this very same machine everything worked as it always did just until I updated from 1.3.0 to 1.4.0. And going back doesn't solve the problem.

[ShayArtzi]

Okay folks so looks like something is going on with 7zip binding on Apple silicon, but unfortunately I don't have one handy so I cannot help troubleshooting

[pskowronek]

I want to mention again that on this very same machine everything worked as it always did just until I updated from 1.3.0 to 1.4.0. And going back doesn't solve the problem.

Was there an operating system upgrade or anything like that in the meantime?

[ErikG-GH]

No, no system upgrade. Still on Ventura because, well, if it ain't broken, don't fix it.
Should have thought of that one when upgrading muCommander...
Just joking.

[ErikG-GH]

Just browsing around:
In the muCommander.app under Contents/app/bundle I find the sevenzipjbindings.jar
It contains 5 platform versions. Only one of them is a MacOs version and that is for intel macs.
I know next to nothing about programming so I really don't know what I am talking about. Just mentioning.

[ShayArtzi]

@ErikG-GH seems like sevenzipjbinding (the library muC is using to handle 7z/rar archives) is not supporting Apple silicon, as mentioned in this issue.

[ErikG-GH]

I found myself a temporary solution to my problem.
From the app/bundle folder inside the muCommander.app I deleted the 2 sevenzipjbinding(s) files.
Results: I can now open my huge folders with rar files. I takes only a small amount of time. I can still see inside zip files and other archives from muCommander. I can't see inside rar files from muCommander (a note about that below) but I have the Unarchiver for that.

note: When I try to see inside a rar file I notice that muCommander tries to use the Unarchiver instead. That app opens and asks permission to unpack it somewhere. When I click cancel the Unarchiver leaves that typical macos file ._filename .
When I look at the huge folders I recently tried to open with muCommander I see thousands of these ._filename files so I guess when muCommander can't use sevenzip with rar files it falls back to the Unarchiver, operating in the background but failing with that amount of rar files.

[ShayArtzi]

Nice! so rn I'm thinking sevenzipjbinding is the root cause for this issue. Hopefully they will support Apple silicon in a future version and then we will include it in muC.

zip archives are handled by custom java native code and does not rely on any native library, therefore it works on any CPU architecture supported by muC.

[ShayArtzi]

@ErikG-GH if you want to give it a try, I was able to compile the sevenzipjbinding from source on an M1 machine and create a patched version of sevenzipjbindings-1.4.1.jar with support for M1 mac (Mac-aarch64).

When I replace the file on the portable version of muC, I'm able to open 7z files on an M1 mac. However, I'm not sure it is possible to do the same trick if your application is installed (under /Applications) because of code signing issues.

Here is a link to the patched version:
sevenzipjbindings-1.4.1_patched.zip

[ErikG-GH]

Thanks Shay. I will certainly try it out but i can’t right now as I am in the South of France and only have my macbook with me and that’s an Intel machine. Within a week I will be back home. Op 9 jul 2024 om 14:51 heeft Shay Artzi ***@***.***> het volgende geschreven: @ErikG-GH if you want to give it a try, I was able to compile the sevenzipjbinding from source on an M1 machine and create a patched version of sevenzipjbindings-1.4.1.jar with support for M1 mac (Mac-aarch64). When I replace the file on the portable version of muC, I'm able to open 7z files on an M1 mac. However, I'm not sure it is possible to do the same trick if your application is installed (under /Applications) because of code signing issues. Here is a link to the patched version: sevenzipjbindings-1.4.1_patched.zip —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Andreas0602]

@ErikG-GH if you want to give it a try, I was able to compile the sevenzipjbinding from source on an M1 machine and create a patched version of sevenzipjbindings-1.4.1.jar with support for M1 mac (Mac-aarch64).

When I replace the file on the portable version of muC, I'm able to open 7z files on an M1 mac. However, I'm not sure it is possible to do the same trick if your application is installed (under /Applications) because of code signing issues.

Here is a link to the patched version: sevenzipjbindings-1.4.1_patched.zip

@ShayArtzi, this does not work for me. It has exactly the same problems as the original muCommander version. But let's wait for @ErikG-GH, maybe he has more luck. Btw., I have muCommander installed under /Applications.

[ErikG-GH]

@ShayArtzi No luck here.
I tried a lot of things, even installed the latest nightly build 1.5.0-snapshot-aarch64 but no luck.
What happens is that after a normal install there is a sevenzipjbindings-x.x.x.jar file in the bundle folder of the app. Also, with the latest 1.5.0 version, when I try to open a rar file it gives an error about the rar being password protected, which it is not, and then the error that sevenzipjbindings couldn't be initialised. Just as already described above. And my main problem stays the same: It fails to open a folder with a lot of rar files.

As I already said, when I remove the sevenzipjbinding file from the app all goes well in that muC uses The Unarchiver to open the rar. It works for me.

Now, your patched 1.4.1 file: In my opinion, it makes no difference. The behaviour is as I described after a new install: It does open an older rar file, it doesn't open a newer rar file and it fails to open a folder with a lot of rar files.

BTW. It takes some time to go through all the different installs and removing/replacing sevenzipjbinding from the app as you have to shut down muC and restart it after any change, otherwise you get unexpected behaviour from muC from parts that are still in memory.

Thank you @ShayArtzi for your work. I am sure that with your commitment we will get there eventually. You noticed that I am speaking of rar files. I couldn't find just now a .7z file somewhere to test. That could still work.

[ShayArtzi]

Hi folks,

Just wanted to clarify some points:

1. the patched version I created will only work with muC portable 1.4.1.
2. After downloading and extracting the above file, the patch I provided needs to be applied (simply replace sevenzipjbindings-1.4.1.jar with the patched veesion)
3. Another missing piece is mucommander.sh needs to be altered, to include the following lines (I'm attaching a patched version):

--add-exports java.desktop/com.apple.eawt=ALL-UNNAMED \
--add-exports java.desktop/com.apple.eio=ALL-UNNAMED \
--add-exports java.desktop/com.apple.laf=ALL-UNNAMED \

mucommander.zip

Patching the "installed" version is not going to work because of code signing considerations.

With the above steps I was able to work with both rar and 7z files on an M1 mac.

All of the above is just a proof of concept to show this issue will be fixed once sevenzipjbindings releases a new version. Let me know if that works for you :)

[Andreas0602]

Let me know if that works for you :)

@ShayArtzi, it does work 👍

[ShayArtzi]

This issue should be fixed in the latest nightly build for apple silicone @ErikG-GH @Andreas0602 FYI if you want to give it a try

[Andreas0602]

@Andreas0602 FYI if you want to give it a try

It works fine. Thank you very much, @ShayArtzi!