Binarynights
ForkLift 4.1.3 introduces some major changes to the View Option Panel. You can open the view options from the menu: View > Show View Options or by using the Command-J keyboard shortcut.
It is now possible to use recursive view settings on the View Option Panel by selecting the “This Folder and Subfolders” option from the drop-down menu at the top of the panel.
We have added the option to change the font inside the panes. The font outside the panes (sidebar, toolbar, preview pane, etc.) can’t be changed.
You can change the font on the View Options Panel by clicking on the selected font type next to “Font”. The default font is called “System Font Regular”. When you click the font, macOS’s built-in font selector opens. Some available fonts don’t work well in ForkLift because they are cut off at the bottom or at the top. Please consider not using those fonts.
After you change the system font, the “System Font Regular 12.0 pt.” font will be added to the “Recently Used” section, but it is possible that it will disappear from that section after a while. Apple generally doesn’t allow users access to the system font, so it is not listed in the font picker. You can restore the system font by Alt-Clicking the selected font on the ForkLift View Option Panel.
If you change the font size in the Font Picker window, that won’t be reflected in ForkLift. If you want to change the font size, you should do that on the ForkLift View Options Panel by changing the “Font size” below “Font”.
By selecting the “Bold Folders” setting, you can make the folder names more apparent.
New
- Connection to Amazon S3 compatible custom endpoints (Scaleway, Minio, etc) is possible
- Option to set recursive view settings on the View Option Panel by selecting the “This Folder and Subfolders” option
- Option to use bold folder names, which can be enabled on the View Option Panel
- Option to use different fonts, which can be selected on the View Option Panel. Going back to the default System Font is possible by Alt-Clicking the selected font on the View Option Panel
- Favorite custom icons are shown inside the tabs. If the same favorite is added to the sidebar multiple times, the icons shown can vary
- ForkLift displays the exact size of items in bytes in the Info Window
- ForkLift can now parse URLs including usernames, passwords, and port numbers when pasted into the Server field on the Connect Panel. In some cases, it also changes the protocol automatically according to the URL
Improvements
- Option to select text inside the About ForkLift window
Fixes
- Fixes a Sonoma bug, which made all color tags gray in the iCloud Drive. Some versions of the tags still appeared gray in the previous version
- Fixes an issue where the same folder name in the path caused a navigation issue
- Fixes a possible crash in the Hungarian version when the “Delete orphaned items” option was enabled
- Fixes an issue, which made it impossible to drag items over the Trash Can in the Dock while using Column View
- Fixes an issue, which displayed the sizes of files as Zero KB after using the “Calculate All Folder Sizes” command
- Fixes a possible data loss during local move operations
- It is not possible any longer to go back to the parent folder by double-clicking an empty space in column and icon view
- Fixes an issue, which didn’t separate the path from the URL on the Connect Panel when connecting to WebDAV
- Fixes some minor localization issues
- Other minor fixes and improvements
Thank you for the colour tag fix. In previous versions I could delete the colour tags from within Forklift but not in 4.1.2. Also If I delete colour tag in Finder it does not delete in Forklift even if I refresh the window.
Note I have to quit delete a nd reactivate for tags removed in Finder to also be removed in Forklift.
Do you have to still do that? Where are those items stored?
Yes this is still the case after several reboots since latest version of Forklift installed. The local files seem to work as expected – it’s the iCloud located files that will not delete colour labels within Forklift.
Thank you for providing more info. I was able to reproduce the same issue. We will look into it.
Thank you for implementing list view font configurability. With a monospace typeface, it really helps my file management use cases.
We are glad you like that option.
Hi, I noticed that on a File as on a Folder, the invocation of the “Services” context menu was sometimes not available: you then have to apply this context menu to other Files or Folders so that finally , it appears.
Very “Feng Shui” all that!…
– Mac Mini M1 16 Go – macOS Sonoma 14.5 –
I wish it would search directly as I type in a pane without clicking the search button, like in the Ubuntu file manager. <3
That feature request is on our feature request list, we might implement it in the future.
Hi, ForkLift 4.1.3 still doesn’t know how to cleanly (and completely) unmount a .dmg file!…
Is it becoming painful…
Do you mean a password protected dmg? Could you please describe what the issue is exactly?
Hi, I’ve already mentioned this problem here, so I’ll repeat myself again.
Whether it is a .dmg file, for example TEST.dmg, with or without password protection, if you double click on this file, the image goes up to the desktop as expected. No problem.
Then, if we unmount this image by clicking on the ForkLift eject icon, the image disappears from the Desktop as expected. No problem.
Finally, if you double click on the TEST.dmg file again, ForkLift does not mount the image!…
EXPLANATION: if we go to the macOS Disk Utility, we can see that the image is still mounted.
I hope I don’t have to explain the bug to you a third time.
That’s because Forklift does not actually eject the .dmg file, it unmounts it. Doing this from Finder actually ejects it. You can simulate the FL behaviour by mounting the .dmg file, then unmounting it (not ejecting) in DIsk Utility and then trying to mount it again from Finder or FL. Perhaps FL should actually eject rather than unmount the file.
That happens because the eject command that we have to use in the code to eject, doesn’t actually eject but only unmounts. Unfortunately, we have no control over the behavior of that command, so we can’t change that behavior.
Hi AgnesBinary, Bryan, thanks for your comments. I understood the situation perfectly well. THANKS.
What bothers me is that with ForkLift 3.5.8, this bug does not exist (I just did the test) and I fall into the trap when I have to reopen the same .dmg file and its image does not rise.
Please note that simple Schell commands from the Terminal have been able to disassemble a volume very effectively and for decades.
Otherwise, we agree, there are much more important things than this problem of software reliability.
The issue you are having is different from the issue Brian and I were describing. I hope that we will be able to fix the issue with remounting.
“What bothers me is that with ForkLift 3.5.8, this bug does not exist”
Actually it’s the same behavior for .dmg files on FL 3.5.8.
…I also noticed that for a NAS volume mounted on the Desktop (and ForkLift for my part does it very well and quickly), this volume is displayed in the Sidebar in the “Shares” section. And if I unmount it by clicking on its icon, this volume is then displayed in the Sidebar, but in the “Devices” section.
Please send us a screen recording of this at support [at] binarynights [dot] com and also let us know what type of NAS you are using. Please record the entire ForkLift window.
Search for a file by Name and “Search in Subfolders” is much much slower on FL 4 compared to FL 3.5.8. In fact, I have to use 3.5.8 for searching.
You can A/B test search speed between FL 3.5.8 and 4.1.3. Try the following on each:
1. Set the search options at the top right to “by Name” and “Search in Subfolders”
1. Go to your home folder
2. Copy and paste “com.apple.assistant.plist” into the search field (don’t copy the quote marks)
3. Wait
On my M2 MacBook Air:
FL 3.5.8 – around 17 seconds
FL 4.1.3 – around 2 minutes 30 seconds
FL 4.1.3 search is about 9x slower!
Hi, I just joined the game (and also to have a little laugh during this difficult time)…
It’s 2:45 p.m.
I just ran the same search (com.apple.assistant.plist) on my Mac Mini M1 16 GB (macOS Sonoma 14.5) with only Finder and Activity Monitor open in the background.
With ForkLift 3.5.8, the file appears after 70 seconds, with a CPU load at 55%… and ForkLift continues searching… 😉
With ForkLift 4.1.3, the file did not appear even though its processor load is more than 110%!… ;-(
With the Find Any File utility (not in an old, non-updated version), the file appeared after 3 seconds.
With the ProFind utility in its latest version, the file appeared… immediately!…
It is now 3:06 p.m.”, the Finder still has not found this file which I remind you is simply in the YourHome –> Library –> Preferences folder.
NB: all its applications have full access to the disks.
I tested on my Mac Mini to search for a file in a sub folder it took a very long time to find it but finder could find it in seconds. very slow search!
The things that all of you have listed, are 3 different things:
1. Search in ForkLift 3
2. Search in ForkLift 4
3. Search in Finder, which is a Spotlight search, which is totally different than the normal search in ForkLift.
You can change the search settings by clicking the magnifying glass in the search field in the toolbar of ForkLift. In ForkLift 4, there are two sections inside the menu that opens:
1. On top (Search), you can see ForkLift’s own search options. ForkLift searches inside the folder which is open in the active tab.
If you don’t select “Search in Subfolders”, then ForkLift filters the content of the active folder. If you select “Search in Subfolders”, then ForkLift searches recursively inside all the subfolders of the active location. ForkLift’s own search engine uses brute force to search, it goes over all the items one by one inside the selected location, which means that the search can take longer if there are a lot of items to go through.
2. At the bottom of the menu, you can also choose Spotlight search, which uses Spotlight’s metadata and can deliver the search results almost immediately. Spotlight search doesn’t work in remote locations, such as SFTP servers.
Spotlight is always running in the background and it collects a lot of info about all items on your Mac and it creates a database of that info. When you do a Spotlight search, only the database gets searched, and the results come back very quickly. ForkLift doesn’t do that, because it doesn’t have its own database, so it can’t give you immediate results, it goes through the files one by one when you start a normal search. So, comparing the ForkLift search with Finder’s Spotlight search doesn’t make sense. If you want to search for local items in ForkLift, and want quick results, you should use the Spotlight search inside ForkLift, and the results will show up very quickly.
Regarding the search speed of ForkLift 3 vs ForkLift 4: I have also run some tests, and you are right, ForkLift 4 finds things located in the “~/Library”, an invisible folder, much slower than ForkLift 3. But in some cases, ForkLift 4 was quicker. It is possible that we are using another search library in ForkLift 4 and it is possible that it goes through the folders in a different order, so it finds items in certain folders later than ForkLift 3. We will take a look at this but most likely this is not a bug but a different behavior.
Search will be much faster if you use Spotlight for local searches.
Hi AgnesBinary, thank you for your long feedback.
You write this:
“2. At the bottom of the menu, you can also choose Spotlight search, which uses Spotlight’s metadata and can deliver the search results almost immediately.”
Sorry, even with SpotLight choices, the file is not found !…
I hope you will not propose to us to delete the SpotLight database !… The performance problem comes from FL 4, it seems.
I’m sorry, I forgot that Spotlight doesn’t index hidden and system folders, so searching for a plist file, which is located inside the Library isn’t a good idea with Spotlight. That folder doesn’t get indexed, so the file won’t show up in any of the listed apps when using the Spotlight search.
The plist files Spotlight found on my Mac were the backup files inside a nested folder in my home.
using ForkLift’s own search engine, ForkLift 4 and ForkLift 3 both find the current and the backup versions of the same plist file but at different times. It seems that the two apps start going through the folders differently and they don’t find the files at the same time. For me, ForkLift 4 finds both files quicker, than ForkLift 3, but ForkLift 3 finds the first file quicker.