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

Long Live HFS?

It's a new file system, yes, but...


Get It

Try It

CUPERTINO (Rixstep) — Apple have a new file system today - APFS - which replaces the antiquated HFS, which in turn replaced the 'let's just forget it' MFS (Macintosh File System). APFS has been a long time coming, but finally it's here.

The specs still haven't been made public, but Apple promised to release them (at some point in time).

There are a few things to note at this juncture.

1. Fast!

APFS seems fast, even though some users have had complaints. Yet one thing is very noticeable: the time needed to remove files. This seems all out of proportion to the task at hand, and markedly slower than HFS.

But as the specs are still not available...

2. Is this really a Unix file system?

APFS doesn't control everything. From the POV of a macOS user, Apple's NSDocumentController has a lot to say.

But one thing is certain at this point: Unix hard links don't work better here than they have on earlier versions of the OS. Which is to say they hardly work at all.

Oh sure, they work from the command line - they always have - but NSDocumentController still doesn't know how to deal with them. Or a number of other things.

  • The 'locked' file. Unix has no such thing as the 'locked' file. But Apple's OS does! The concept seems to be born out of the frustration of higher-ups in the company who couldn't understand why their write-protected files were write-protected. Or some other such nonsense.

    Given how NSDocumentController will customarily save user files (intermittently) to a neutral location before finally copying them to their real destinations on user-explicit saves, the solution seemed readily accessible: change those copy ops to moves.

    [You can see if they're still up to this hanky-panky by keeping track of the inodes. Ordinary (sane) file saves don't change the inodes. The files are opened for writing, using (of course) the same inode. Ed.]

    And that's about as far as they thought. And the solution undoubtedly put smiles on a few California faces. Except it really doesn't work.

    Apart from violating just about every system architecture rule in the book, the method is dependent on the parent directory being accessible for writing. And if it's not, the OS user - to this day - gets a cryptic (and confusing) message to the effect that there's something wrong with a file rather than a directory.

    Like this.

    System engineers indeed.

  • Test hard links from inside a vanilla Cocoa (?) application.

    Here are the info sheets for what appear to be two separate files.



    But if you check the 'Inode' field and 'Links' field in both, you'll see they're one and the same file.

    This is accomplished not by relying on Cocoa, but by using file management intrinsics. For as soon as you save the document again, the picture changes, and they're not the same file anymore.

    But whereas HFS had an excuse (sort of) APFS should have nothing of the kind.

    [NSDocumentController's intermediary saves are to /var/folders/.../T/TemporaryItems, another of your myriad dynamically system-defined temporary directories, accessible through NSTemporaryDirectory(). Ed.]

  • There's another test. CNIDs can be traced back to unique file paths, but inodes can't. Meaning Unix can't find a file if it's been moved. Can APFS with 10.13?

So if APFS doesn't have a super-secret directory at root to hide multi-linked files...

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.

CONTACT INFO:
John Cattelin
Media Contact
contact@rixstep.com
PURCHASE INFO:
ACP/Xfile licences
User/Family/Business
http://rixstep.com/buy
About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.