Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

'Does anyone else feel that file management still sucks on macOS?'

Apple have never and will never 'get' filesystems.


Get It

Try It

CUPERTINO (Rixstep) — The question posed on Reddit on 30 September 2016 was:

     'Does anyone else feel that file management still sucks on macOS?'

The answer should be a resounding 'yes', but most fanboys will be silent. The only ones who speak up are those dabbling in other systems. The admins know better by now than to say a word.


But let's look a bit at what 'WTellie' has to say - after all, he says:

     'I've been a Mac user since the Macintosh SE'

WTellie has a list of bullet points.

  • File operations regularly block the entire operating system.
    'Regularly, my entire system beachballs, Safari stalls and even the text I'm writing right now will lag for about six or seven seconds before suddenly appearing all in one go.'

    Yep. Poor multitasking. Not a lot one can do. User threads are prioritised more on user systems, filesystem operation threads more on file servers. Macs are not file servers. Remember that 1) this can be down to distribution of time slices, but 2) I/O should be capable of running independent of CPU activity, but 3) Safari is intense when it comes to filesystem activity.

  • File operations routinely fail with "error number -###".

    Yep. And this is bad. This was dumb already back in the days of MacOS but it's inexcusable now and has been for the past 20 years. Even basic Unix error routines will offer more - see our Lightman for an example. Using an archaic 'MacOS' error code - and offering no more than that error code - is simply lame.

  • Resuming something is impossible.

    This is asking for overkill, and it's a lofty thought, but it's a bit much. But of course there are exceptions, and they should be dealt with.

  • Conflicts are blocking.
    'If there is a duplicate file conflict, the entire operation stalls until I can chose if I want to cancel or overwrite. The operation does not continue with the non-conflicting data in the background.'

    Clark Kent is out of the office. Please leave your name and number and he'll get back to you.

  • There is no conflict handling.
    'Should a file or folder already exist, I'm basically presented with the choices between overwriting or cancelling the entire operation. I cannot review the conflict, and I cannot manually take steps to mitigate the conflict after the operation has started.'

    You're in the middle of what should be a new independent thread of execution, dude. You should see this onscreen in the best of all possible cases. Apple code is weak or nonexistent in secondary threads. But you want interaction on top of your already present interaction?

  • Folders cannot merge.

    Yes, this is true, and perhaps the biggest superficial eyesore in filesystem intrinsics. Everything seems to have been set from Apple One to work this way. It makes life easier for the system authors for sure, but it makes life a pure nightmare for everyone else. How many major system catastrophes have people experienced on Apple's platforms? Then add to this: no other system known to man works that way. No other system. Only Apple. And it's not something to be proud of.

  • Progress indication and time estimation sucks.

    So you basically want First Class to the moon and back, a visit to the cockpit and control centre, and a steady supply of Dom Pérignon?
        

  • No pause.

    Has anyone ever offered this?

  • No queue.

    See above. And if Microsoft can offer these features in their file manager, then good for them. What a shame, of course, that it runs on Windows, but still and all.

'Good morning, Dave'

But of course the big elephant in the room is encapsulation. And it's true: Apple never got this and never will. The company with the biggest market cap in the world, and they still have NFC when it comes to filesystems.

And of course this isn't new: it was all over the old Carbon documentation in red print. 'Oh please don't do this, oh please be careful with this, you can hose the entire filesystem!'  Stuff like that - and yet left open for the entire world to abuse.

Postscript

Let's not get into the comments at that Reddit page: the one's more clueless than the other. Those who do know what's going on are working and too busy to comment. Those who don't know are the only ones who have time to comment. And it shows.

'Some of this is due to the antiquated HFS+ file system' No it's not.

'The system locking is partially due to the file system design' No it's not.

'Windows Explorer is still the best at file management. Nothing else on any OS I've used (including Linux) comes even close.' WINFILE is a Cutler rewrite of the original, which was pretty spectacular in its own right. But ultimately couldn't handle 'long file names'. Almost anything coming from the 'Tribe' was good - save for their halfhearted approach to security (for which they may be excused).

'Quite frankly, HFS+ is probably the worst filesystem ever. Christ what shit it is.' Perhaps, but APFS can't match it for deleting files. Development of APFS is far from complete.

'Everything file related sucks on macOS, APFS can't come soon enough.' The one isn't connected to the other.

'The tools to perform file system operations and the UI needs to be revamped.' Crickets. The reason Rixstep have their own file manager (and tool suite) is because Apple's file manager is simply unusable, and the alternatives are simply not satisfactory. After writing their own file manager for Windows over a period of one year ten months, they could hardly have been in the mood to do it all over again. Gnome and KDE have acceptable file managers.

'APFS won't fix the crappy way they deal with things like folder merging and other conflicts...' No, and the connection is weak, but no, it won't, and this is a shame. Apple won't change. There have been so many major scandals already, and if they haven't changed yet, you know they're not going to do it now.

'It's interesting that Apple never decided to complete the transition to doing filesystems the Unix way, including case sensitivity' That's a minor issue. How about hard links? Read Apple's documentation for programmers which speaks of hard links between files. And you know that no copyeditor made that up. That had to have come from a programmer in the building. And if that's the way they think of hard links, then you know that they don't know shit about Unix.

WebKit

Now here's something that's both apropos and interesting.

     https://webkit.org

Tech Name: Domain Administrator
Tech Organization: Apple Inc.
Tech Street: 1 Infinite Loop
Tech City: Cupertino
Tech State/Province: California
Tech Postal Code: 95014
Tech Country: US
Tech Phone: +1.4089961010
Tech Phone Ext:
Tech Fax: +1.4089741560
Tech Fax Ext:
Tech Email: Apple-NOC@APPLE.COM
Name Server: NSERVER2.APPLE.COM
Name Server: NSERVER.APPLE.COM
Name Server: NSERVER3.APPLE.COM
Name Server: NSERVER4.APPLE.COM
DNSSEC: unsigned

WebKit? How does this apply? OK, anyone who wants a coffee break to think it over, you're welcome. Go ahead.

Here's another example.

     https://developer.apple.com/documentation/appkit/nsworkspace/1533391-urlforapplicationtoopenurl

     'This is the programmatic equivalent of double clicking a document in the Finder.'

Somebody needs a whack from a clue bat.

David Maynor

Most fanboys remember the name David Maynor. A few might remember the name Johnny Ellch. Maynor worked with infosec for an IBM subsidiary, and Ellch worked at a US Navy computing lab in Monterey, California.

But of course neither of them had the skillset of the great Gruber. And poor Brian Krebs got chewed like pirañha lunch for covering their discovery.

But what had they discovered? Actually it was Ellch who made the discovery, and Maynor who made it possible for other people to understand what Ellch discovered. (And Krebs who got to witness a 'hijack' the night before with an OOTB Apple laptop.)

One of the likely reasons Maynor was able to understand was that he'd come upon similar insight on his own some time earlier: the thought that a personal computer was actually a constellation of 'computers within a computer'. What happens, for example, if you have a driver monitoring a port, and running in kernel mode, and funky code is able to enter that port, screw up the driver, and take control of it? As that code's running non-paged, can't it screw up other stuff too? Such as DMA? Start writing random (or not-so-random) stuff to physical memory? To the file system? And beyond?

Maynor was becoming aware that each sovereign component of a personal 'computer' had to be able to defend itself - from other sovereign components. So the drivers had to better defend against other drivers, the file system against them all, and so forth.

This is a bit of the thinking of David Neil Cutler, who wrote DEC's RSX and VMS, and later DEC's and Microsoft's WNT. He called the latter systems 'object-based'. They were encapsulated, self-contained, self-protecting. His original design for WNT was as a file server. He didn't know what they'd run on the workstations, and he couldn't care less.

A Cutler file system is impregnable. You can't get at it. And that's the whole point - that's the way it should be.

And Apple will never see that. What people will instead see is red text in programmer documentation and shitloads of deprecations.

And the occasional super-scandal as someone's poor data gets blown to smithereens and the fanboys gather en masse to attack the sod for not having the decency to STFU.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.