Home » Learning Curve
Hello, AppleSome things never change. Others stay the same.
MURRAY HILL (Rixstep) — This is an easy story to tell. And it's also a difficult story to tell. It can (will) have two demographics. The one will already know the punch line, the other won't want to hear it again.
Kernighan/Pike
Let's assume we're dealing with someone who recently arrived at macOS. Its a Unix, right? Its kernel is called XNU, which stands for 'X is Not Unix', but does that matter? They've got the old head of FreeBSD onboard. It's Unix, right? It's got the 'bin' directories for all the Unix utilities, right?
Right. So let's open our Unix Programming Environment and dive in.
One of the first things - the first thing - Brian likes to do is print out 'Hello, World'. This is essential, he explains in his C book, because you have to get the 'environment' up and running. Creating the first C program for that is a bit different from interfacing with the Unix (macOS) system, but the principle is the same. Let's paraphrase BWK a bit. Let's start a text file with the following contents.
echo Hello, World
That's it. So let's save it to disk and then run it. Right away on macOS we run into a snag.
$ ./hello
-bash: ./hello: Permission denied
This part is expected, and Brian takes pains to explain why. One has to enable the script file for execution. One has to set the 'x' bit in its mode.
But where? How?
Back in the day when Brian and Rob Pike wrote the book, there was only one way. All they had was the command line. But today we have a GUI, right? Today the newbie macOS user has Finder, right?
And there Finder is, stuck on the far left of the Dock. And it doesn't want to go away or be sent away.
Finder is part of the change that took place when Steve Jobs returned to Cupertino. The NeXT interface was run by Workspace Manager, the Dock, and File Viewer. File Viewer was replaced by Finder, an old 'MacOS' standby, and Workspace Manager was more or less vanished from the scene.
But Finder can deal with file modes, right?
Good luck.
Mess around all you want with Finder of today and you won't see how it's done. And there's one click area which inexplicably summons up an authentication dialog - more on that later - but that won't help either. All you get is the choice between 'Read only' and 'Read & Write' - no eXecute bit.
And this is only scraping the surface.
Dumbed Down
Apple's default macOS user interface is infamously dumbed down in the extreme. One can fathom a certain justification for this - that's not at all hard. Imagine what would happen to those rows of showroom MacBooks if customers could run rampant. Also important: what about people who bring a MacBook home? The whole image is that it's simple to use. The Dock is drastically simplified from the days of OPENSTEP. There's not too much to assail the new user. Nothing threatening. It's admirably simple. And functional.
But what about the power user? What about someone who wants to study the Unix Programming Environment?
The command line of course. And where is the command line? It's Terminal.app, a GUI application. And where is Terminal.app? It's in /Applications/Utilities, so it takes a bit of navigation to get there. And hopefully not too many store visitors will bother, and hopefully not too many users in general will make their way over unless they know what they're doing, right? For if they screw up and hose their machines, they'll blame Apple, you know they will. And Apple's HI group know it too.
But couldn't they have an 'Advanced' section on Finder's menu, like Safari has 'Debug' and 'Developer'? Same thing most likely. Users will screw up and blame Apple. As an Apple server researcher told us: 'we don't want you going there!'
But wouldn't it be easier if... No, they'll tell you. File Viewer is now Finder, the Dock no longer has tabs, and what is Workspace Manager anyway?
But that's only the beginning.
Hard Links
At Apple they talk of 'multi-linked files', but in the world of Unix (POSIX) they're called 'hard links'. They're possible thanks to Ken Thompson. A physical file resides in only one location in a filesystem, but there can be any number of names/paths to that physical file. Unix directories have only filenames and index numbers. All other data is stored in a separate volume control block (ilist). So if a directory has only pairs of filenames and indexes, there's nothing to prevent the system from pairing up an index with another filename - perhaps in another directory.
There are uses for this. Unix (and macOS) programs take their full path as the first argument to their (often unseen) command line. The program can behave differently depending on what path and filename were used to invoke it.
Apple filesystems have always been at odds with Unix architecture, chiefly because Apple HI people want to see that, for any physical file, there is only one path resolution (which can be determined by the system). /.vol is part of this trick. But such one-on-one doesn't exist in Unix, leading to the infamous '␀␀␀␀HFS+ Private Data\r' directory under root.
But it doesn't stop there. Today it carries over to standard file-saves as performed by Cocoa's document controller. The old 'NeXT' way of saving files involved first storing them in a neutral temporary location, then copying them in to their final destination. Any hard links in use were preserved.
But when someone decided to introduce the 'locked/unlocked' idea, things changed. The same basic 'save' method as before was still used, but when it came to the all-important final file-write, the file was moved instead of copied, thereby breaking the hard links, as the old file was no more, having been replaced by a new file.
Any scripts you have which are also multi-linked? Be careful editing them from the macOS GUI.
And still we're not through.
SetID
Unix files (and macOS is a POSIX-compliant system) can have three more bits, in addition to the ordinary r-w-x: set user ID, set group ID, and the sticky bit.
Dennis Ritchie invented the sticky bit, applied for a patent in 1973, was awarded the patent in 1979, and thereafter put it in the public domain. The sticky bit was initially used to flag files that shouldn't be swapped out of memory. Today its use depends somewhat on which Unix flavour you're using. Apple's macOS uses the sticky bit to prevent files being deleted by other than their owners.
The set user ID and set group ID bits are used to escalate privileges. sudo uses this, and then performs myriad security controls before forwarding a command line.
All of the above is invisible, not only in Finder, but also in its other manifestations. If there's something's strange in your filesystem, and if it's down to bits like that, Finder won't tell you and won't help you either.
But yes, there's still more.
File Flags
Now it's time for the file flags. These can really screw up things, and for the same reason as above: Finder can't get at them.
These file flags can (must) be divided up into two categories: user flags and system flags. User flags include the self-explanatory 'no unlink' and 'immutable'. These flags can be set (and reset) by the file's owner (user).
System flags are a bit different: they can only be reset in single-user mode. This means that not even escalation to root is enough: you have to boot into single-user mode to get at them.
Once again, you'll see no hint of their existence in Finder. You might get frustrated that some files won't go away, that you can't empty your Trash, but Finder won't do it for you, and won't even tell you what's wrong and how you fix it.
There's more.
ACEs and ACLs
Yet another form of access control: access control lists. Access control lists have access control entries (seventeen in number). These entries allow or deny access to a file. File flags rank higher, but ACEs and ACLs preempt ordinary file permissions.
A curious encounter occurred when poking at Finder (see above). An authorisation dialog suddenly appeared onscreen. After authentication, the selected file acquired an access control entry. This entry was not as trivial as Finder let on, but could be removed without authorisation.
Untouchable Mounts
Neither will (can) Finder get at all 'mounts' in your filesystem. You can see these mounts (eg /dev) from your command line, but not in Finder. /dev is your devices directory, and it's populated at boot time. There's quite a lot of useful information in that directory.
Mounts
------
/
blocks: 29571062
blocks free: 11339094
blocks available: 10646822
block size: 4096
inodes: 9223372036854775807
inodes free: 9223372036853703566
flags: 0480D000
MNT_DOVOLFS
MNT_JOURNALED
MNT_LOCAL
MNT_MULTILABEL
MNT_ROOTFS
file system ID: 01000004 00000019
file system type: apfs
I/O size: 1048576
mounted from: /dev/disk1s1
owner: 0
type: 25
/dev
blocks: 370
blocks free: 0
blocks available: 0
block size: 512
inodes: 640
inodes free: 0
flags: 04101000
MNT_DONTBROWSE
MNT_LOCAL
MNT_MULTILABEL
file system ID: 265F4800 00000013
file system type: devfs
I/O size: 512
mounted from: devfs
owner: 0
type: 19
/home
blocks: 0
blocks free: 0
blocks available: 0
block size: 1024
inodes: 0
inodes free: 0
flags: 04500000
MNT_AUTOMOUNTED
MNT_DONTBROWSE
MNT_MULTILABEL
file system ID: 32000002 0000001A
file system type: autofs
I/O size: 512
mounted from: map auto_home
owner: 0
type: 26
/net
blocks: 0
blocks free: 0
blocks available: 0
block size: 1024
inodes: 0
inodes free: 0
flags: 04500008
MNT_AUTOMOUNTED
MNT_DONTBROWSE
MNT_MULTILABEL
MNT_NOSUID
file system ID: 32000001 0000001A
file system type: autofs
I/O size: 512
mounted from: map -hosts
owner: 0
type: 26
/private/var/vm
blocks: 29571062
blocks free: 29046769
blocks available: 10646822
block size: 4096
inodes: 9223372036854775807
inodes free: 9223372036854775805
flags: 14909004
MNT_DONTBROWSE
MNT_DOVOLFS
MNT_JOURNALED
MNT_LOCAL
MNT_MULTILABEL
MNT_NOATIME
MNT_NOEXEC
file system ID: 01000007 00000019
file system type: apfs
I/O size: 1048576
mounted from: /dev/disk1s4
owner: 0
type: 25
Postscript: FIFinderSyncExtensionHost
Running Finder is never a thankful task. Most important is to rid one's filesystem of those dainty drops of do-do known as .DS_Store. On this particular occasion, after again banishing Finder to Beigeland, a single such file was encountered. Of course it already had acquired two (2) extended attributes - what else - but the journey there proved educational as well. Apple have had a 'sort of' conflict in their frameworks for some time. It doesn't seem to harm anything, but it's been there for some time, and, after all, it's actually Apple warning about suspect behaviour on the part of - Apple.
|