Best alternative File Manager to Finder? Recommendations please....

[svenmany]

Whoa! I'll check Finder to see if it works for me now or not. (I haven't used Finder for the last few years because of this issue.)

Well ... it's now even worse in my humble opinion because Finder is now inconsistent, let me explain.

I created a new directory named "Testing" and in this directory I created a new file named "._test-finder.txt".

If I use Finder to Copy-n-Paste the "Testing" directory to a new location, then the directory is copied but the copied directory does NOT contain the file named "._test-finder.txt". On the other hand, if I Drag-n-Drop the original "Testing" directory to a new location, then in the new location the "Testing" directory still does contain the "._test-finder.txt" file.

In summary, as of today under macOS 14.3.1 the Finder's Copy-n-Paste misses "._*" files while the Finder's Drag-n-Drop does not miss these files.

I still have the results of all of the tests that I performed a few years back, and when I checked these old results, both of the above tests failed to copy/transfer "._*" files, so it appears that Apple has fixed one problem but not the other problem --- thus the results using Finder are now inconsistent. It was bad enough that Apple's Finder missed these "._*" files before, now Finder is inconsistent in its behavior --- sometimes missing "._*" files and sometimes not. Makes me worry about how other utilities might be altered.

I'll have to repeat all of my earlier tests of all of the ways to view/copy/transfer files.

Again, as of today, both the Homebrew "gtar" and "rsync" do NOT miss files when copying/transferring. I thus recommend that one employ these utilities for now to copy/transfer directories/files and we'll see how Apple alters the behaviors of their other utilities in the future (of course, only if you use Windows files or certain databases that employ "._*" filenames).

Thanks,
Solouki

Thanks for all this. It’s great information that could save me a lot of trouble in the future.

 

[svenmany]

I was speaking about those APIs. They carry the very philosophy behind Finder: each column has a single level.

I suppose that Wine makes a "remote" access to the file system?

They have different presentations, but work pretty much all the same way than Explorer.
MacOS is fundamentally different.

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.

 

[Miles Fu]

I rely on Total Commander on Windows, So I choose Forklift on Mac

 

[gilby101]

In summary, as of today under macOS 14.3.1 the Finder's Copy-n-Paste misses "._*" files while the Finder's Drag-n-Drop does not miss these files.

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

Again, as of today, both the Homebrew "gtar" and "rsync" do NOT miss files when copying/transferring. I thus recommend that one employ these utilities for now to copy/transfer directories/files

Except maybe in unusual circumstances, I don't recommend using utilities to circumvent the correct use of ._ files.

 

[solouki]

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.

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.

 

[gilby101]

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.

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.

 

[solouki]

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.

 

[Diskutant]

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.

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.

 

[solouki]

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.)

 

[rin67630]

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.

If it could, it would have been done.

 

[svenmany]

If it could, it would have been done.

Millions of things could be done that haven't been.

 

[gilby101]

With drag-n-drop you are moving the folder, the files aren't touched, therefore the ._ files are still in the folder.

Have you tested that? In my tests, the ._ files are not in the drag-n-dropped folder.

 

[svenmany]

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.

 

[gilby101]

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.

The subtle variation was that I did it wrong!

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.

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.

 

[brsilb]

Both Forklift and Qspace "throttle" copying files to my connected One\Drive. Finder works perfectly.

 

[svenmany]

Both Forklift and Qspace "throttle" copying files to my connected One\Drive. Finder works perfectly.

Can you provide some metrics for that? I'd like to test on my computer and see if I get the same behavior.

 

[brsilb]

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.

 

[svenmany]

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.

 

[svenmany]

If it could, it would have been done.

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.

 

[gilby101]

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.

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.

I don't know how to set up a special connection to use with Finder. How did you do that?

Mountain Duck is my preferred way of integrating One Drive with Finder.

 

[rin67630]

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.

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.

 

[svenmany]

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.

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.

 

[svenmany]

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.

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.

 

[rin67630]

I had a feeling you'd try to wriggle your way out of this one.

I can't prevent you to have feelings.

 

[gilby101]

Also, the performance is so bad that there's got to be something else going on.

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.