Thanks for all this. It’s great information that could save me a lot of trouble in the future.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Best alternative File Manager to Finder? Recommendations please....
- Thread starter pax-eterna
- Start date
- Sort by reaction score
You believe that the Wine Explorer presentation cannot be reproduced in a native mac development environment. I believe it can, easily. Commander One is close to that, without the tree on the left. And the tree on the left is trivially reproducible by using the normal mac tree while suppressing the file listings inside the folders. And two panes can easily placed adjacent to each other with click events propagated between the two. But, I can't prove it without doing it. So I yield.
My testing with 14.3.1. I have tried on a folder to Copy-n-paste, Drag-n-drop, Drag-n-Drop with option key, and duplicate folder. Nothing copies the ._* file (using Finder).
But, ._* files have a special role in macOS to hold attributes and resource forks on file systems which do not support them. We should not be creating them in APFS/HFS+ volumes and should not be copying them and expect them to be preserved.
I believe that Finder's behaviour is correct to never copy them on APFS/HFS+ volumes. At least most of the first 3 answers here are still current: https://apple.stackexchange.com/que...rscore-files-created-and-how-can-i-avoid-them
Except maybe in unusual circumstances, I don't recommend using utilities to circumvent the correct use of ._ files.
Last edited:
Thanks.
The problem for me is that I am occasionally sent a database that employs ._ files and when these were not copied the database was not properly usable.
And yes, I agree that most users won't encounter ._ files, but I think Apple should at least be consistent in how they handle these files; Apple's tar doesn't archive them but rsync does transfer them while Finder does not, except for Drag-n-Drop. Apple is also inconsistent in how ditto, shar, pax, tar, rsync, cp, scp, sftp, dd, zip, etc. treat these files.
That's is a problem.
All I can suggest is to have a look at the Finder alternatives. I have:
Path Finder and Transmit, both are copying "._" files as you would like it.
QSpace and CommanderOne don't see "._" files even with show hidden files!
I don't know about Fork Lift - the other popular alternative.Or, as you are doing, use a command line utility which does copy them.
Thanks for the recommendations gilby101, but I switched to Fink's/MacPorts's/Homebrew's "gtar" and "rsync" years ago and haven't really missed the GUI's Finder -- I'm faster typing commands into a Terminal and much faster using shell scripts for complicated manipulations than using the GUI. Plus, I can execute the shell scripts from a remote SSH login without needing to share the remote computer's screen.
Thanks again, I appreciate your time and the suggestions,
Solouki
P.S. I still consider this a "bug", especially since Apple's own utilities are inconsistent with the most glaring bug being the fact that the Finder's Copy-n-Paste does not work properly while the Finder's Drag-n-Drop now does work. If not for the inconsistencies, I could accept that this issue was a "feature decision" on Apple's part. At the very least, Apple should change their documentation, say their "man pages", to describe this issue -- I had to find it the hard way, and then test all known ways of copying/transferring files to discover what worked and what didn't. Unfortunately for me, because I had some old data archives created by Apple's "tar", I did loose some time and effort recovering the ._ files missed by Apple's "tar". But with the GNU/Linux "gtar" replacement, I haven't had any problems since.
Last edited:
Well, with copy-n-paste each file needs to be copied. They skip the ._ during that.
With drag-n-drop you are moving the folder, the files aren't touched, therefore the ._ files are still in the folder.
Yes, that is true. But, intriguingly, a few years back when I tested all known methods for copying/transferring files, I found that neither Copy-n-Paste nor Drag-n-Drop would copy/transfer the ._ files. I still have the results of my tests, and this is what I found a few years back neither Finder tool would copy/transfer ._ files. I was a little surprise that Drag-n-Drop now does transfer the ._ files, as it didn't in the past. Today the Apple tools are just inconsistent, with some working (meaning they copy/transfer ._ files) and some not.
(When I tested Drag-n-Drop years ago, I thought that the ._ files should come along since they were contained in the overlying directory, but that wasn't the case -- it seemed that since Apple's Finder didn't report the ._ files, then Drag-n-Drop also didn't transfer the ._ files, they were just missing after the Drag-n-Drop as if Apple purposely deleted them. Under macOS 14.3.1, now Copy-n-Paste works this way, after Copy-n-Pasting a folder containing ._ files, the folder is copied and all of the folders files are copied except for the ._ files --- these ._ files are just missing.)
Have you tested that? In my tests, the ._ files are not in the drag-n-dropped folder.
I have tested it. Using Finder, the drag-n-dropped folder has the file. Perhaps there is some subtle variation to how we are doing this that affects the result.
I created two sibling folders, "f1" and "f2". In the f1 folder I created a file named "._bozo.txt". Then I dragged f1 into f2. The relocated f1 still had the "._bozo.txt" file in it.
The subtle variation was that I did it wrong!
I think my previous testing was wrong. I have done it again:
Drag-n-drop (move) the folder and the ._ moves with it.
Option-drag-n-drop (copy) and the ._ is not copied.
Obviously I added to the confusion - sorry to both of you about that.
Can you provide some metrics for that? I'd like to test on my computer and see if I get the same behavior.
Just installed them, did the connect to Onedrive process. It brought up Microsoft dialog to"allow". Then copied a 14GB folder and all its files to OneDrive. Said it was preparing and in a few minutes got the throttling message. There was no evidence that any copying was taking place as I waited about 1 hour. I used the finder to copy to on e drive folder and it worked.
For me, QSpace and Finder behave the same if I just copy a file to the OneDrive folder and let the native OneDrive sync take care of it. When I use QSpace to set up a special connection and use that connection, then it crawls. I don't know how to set up a special connection to use with Finder. How did you do that?
-- EDIT --
As an aside, the native OneDrive sync talks IPv4 to *.storage.live.com. QSpace and Forklift use a different API and talk IPv6 to graph.microsoft.com. Microsoft could easily be deprioritizing the latter.
Last edited:
I found someone who wrote one in 2011 - https://codereview.stackexchange.com/questions/4446/file-browser-gui/4451#4451. It was pretty straightforward (I looked at the code) and doesn't use Finder. I bundled it up and made an executable
https://filetransfer.io/data-package/VZfJ6TQs#link
It shows a tree on the left (only folders, no files). On the right is a list of the files with columns of attributes.
No one has written a full-blown application with this kind of presentation because they probably figured it wouldn't sell well and wasn't worth the time. A Mac audience mostly wants Mac idioms for file management.
I rate deprioritising as very unlikely because: 1) there are lots of apps that use graph.microsoft.com and for purposes more than just file sync, and 2) other cloud services have equivalent/competing APIs.
Mountain Duck is my preferred way of integrating One Drive with Finder.
Aaarg ! A file browser that builds up it's file hierarchy by scanning all folders manually?
Welcome in the 19th century!
It's not only about having a tree on the left. That's a too simple way to look at things. Explorer is used in every file transaction and can be used on the fly (e.g to delete/rename an unwanted file while saving).
The APIs of Finder are also used in every file transaction but in a rather unconsistant way. Many things are done differently (e.g. navigate back in the hierarchy is solved differently).
If you chose an alternative file manager, that will not change the file saving transactions, which adds inconsistancy.
A Mac audience mostly may want Mac idioms for file management for above mentioned reason and also because they are unaware it could be done better.
I had a feeling you'd try to wriggle your way out of this one.Aaarg ! A file browser that builds up it's file hierarchy by scanning all folders manually?
Welcome in the 19th century!
It's not only about having a tree on the left. That's a too simple way to look at things. Explorer is used in every file transaction and can be used on the fly (e.g to delete/rename an unwanted file while saving).
The APIs of Finder are also used in every file transaction but in a rather unconsistant way. Many things are done differently (e.g. navigate back in the hierarchy is solved differently).
If you chose an alternative file manager, that will not change the file saving transactions, which adds inconsistancy.
A Mac audience mostly may want Mac idioms for file management for above mentioned reason and also because they are unaware it could be done better.
But yeah, if they don't do it the way you like then they use Finder. There are tons of ways to implement the UI that you showed in Wine and I showed with my example. There are nice GUI libraries that make it easy. I'm sorry you're unable to imagine getting this done without using Finder to do it.
I'm going to give Mountain Duck a look. I do wonder what @brsilb was using.
But, I don't think they would ever prioritize graph.microsoft.com. But there's a chance they would deprioritize it's usage accessing OneDrive over its own native usage. But, it's a stretch. Also, the performance is so bad that there's got to be something else going on.
I might try disabling IPv6 on my network temporarily and try with IPv4. Comcast had some issues the other day that disabled my IPv6 for a short while. Perhaps there are some lingering IPv6 issues at my place.
Caveat:My knowledge as a developer is many decades(!) out of date. It is relatively easy to get something going with OneDrive (via graph.microsoft.com) to give basic functionality. But it takes some effort to get reasonable performance (in the sense of MB/s) - e.g. it needs multiple data streams.
In terms of MB/s performance, my experience as a user is with Arq Backup (with OneDrive as cloud storage) and GoodSync (scheduled sync local folder with OneDrive folder). Both to my mind have reasonable performance, but I am seldom wanting to send/receive large quantities of data. I have seen no sign of them being throttled.
My use of Mountain Duck is as an alternative to the MS OneDrive sync. It has a file cache (can be on external drive) and presents your OneDrive as an NFS volume. The advantage of NFS is that it is an in-built file system that does not require any kext or third-party system extension. I have never had the need (big file changes) to investigates its MB/s performance.