Home » Industry Watch » The Technological
Dog of Bride of Son of Massive Data LossA tantalising April treat.
Further bugs uncovered in Apple's next generation operating system. Actually not the operating system per se (which is relatively healthy thank you) but their notorious 'FF' that's evidently still not 'F'd.
It's things like this - seen by punters as mere bugs - that raise the eyebrows of professionals in the enterprise. There's no way the system and its ancillary tools can be taken seriously if the organisation of the system's underpinnings is so shambolic.
For it's not a mere bug. But more on that later.
The following turned up at the venerable Mac OS X Hints forum three days ago.
Comments following expressed everything from surprise the bug (assuming it was the same bug) was still not fixed to astonishment and outrage.
One might at this point insert a few acerbic comments about Kool-Aid drinkers using the 'FF' deserve what they get but that would only waste time. Far better instead to attempt to analyse the 'bug' to see exactly what's going on.
- The 'folder' 'DDD' ('destination destination destination') is supposed to be 'locked'. This is diffuse. It's Kool-Aid talk™ for setting one or more special system/user flags. But 'uimmutable' ('user immutable' - 00000002) should do it.
 
- The 'folder' 'SSS' ('source source source') doesn't really need any files in it. And it doesn't need to be a 'folder' either. The test involves seeing if the immutable flag on 'DDD' holds.
The immutable flag is supposed to both 'freeze' the contents of 'DDD' and freeze its existence itself: you're not supposed to be able to even delete it from its parent directory.
- Copying or moving 'SSS' into/to 'DDD' doesn't really matter if the system is working properly. Both operations are supposed to fail.
- Asking for a password at this juncture is total crap. There has been no privilege escalation used to get you into this mess. Consequently there should be no privilege escalation needed to get you out.
You have three choices here and none of them are rosy coloured. Either the system has no real clue what it's up to; or the system is trying to cheat itself; or both the above.
- Progress bars, disappearing 'SSS' 'folders' - that's the 'FF' and doesn't apply anywhere else thankfully.
So what's going on?
For the bug to rear its ugliest head you have to have your source on a different volume. This is because although the system makes these operations look seamless they actually aren't.
File 'move' operations within the same volume don't actually move any files - they only move directory entries. The files already exist; they'll stay accessible by their same inodes; it's just the paths to those inodes that change.
File 'move' operations across volume boundaries can't work the same way. The destination doesn't have the source files stored. They have to be effectively copied instead.
But the idea is to make the operations look like traditional 'move' operations. So what you're supposed to do is #1) first copy the files to the new volume; and then #2) remove the files from the source volume - but of course only after verifying the copy operation completed successfully.
The flags are specified as an octal number or a comma separated list of
keywords. The following keywords are currently defined:
arch set the archived flag (super-user only)
opaque set the opaque flag (owner or super-user only)
nodump set the nodump flag (owner or super-user only)
sappnd set the system append-only flag (super-user only)
schg set the system immutable flag (super-user only)
sunlnk set the system undeletable flag (super-user only)
uappnd set the user append-only flag (owner or super-user only)
uchg set the user immutable flag (owner or super-user only)
uunlnk set the user undeletable flag (owner or super-user only)
archived, sappend, schange, simmutable, uappend, uchange,
uimmutable, sunlink, uunlink
aliases for the above |
But for some reason Apple aren't about to explain - even if they themselves know or someday should find out - an anonymous programmer ensconced there at One Infinite Loop saw the world through a pair of rose coloured glasses and said to himself: 'what could possibly go wrong?'
But you simply don't do things like that in the enterprise. It's OK - if not forgivable it's recoverable - in a small graphics shop with four or five computers and the time to scramble to fix a data loss. But it's none of the above when money is on the line and hierarchies of suits want results and want them now and are not about to accept what the faithful Kool-Aid drinkers at Mac OS Hints forums accept.
Which is why for all their fancy designs and cool image Apple will not be taken seriously and the enterprise will continue to stick with Microsoft's 'third rate products'.
Unix itself does not fail in this regard - as evidenced by the screenshots seen on this page. This is Rixstep's Xfile and Xfile is a 'Unix' file manager. Which means it uses only Unix APIs for the important stuff and uses absolutely no Carbon or legacy 'beige box' APIs. Which means it works against a consistent system interface.
But the 'FF' does not work against a consistent interface. It's more like a quilt. Apple continue obstinately to attempt to interlace conflicting technologies, to refuse to let go of the old, to avoid 'stepping into line' with the other Unix platforms out there.
Claims Apple as a corporation neither understand nor appreciate Unix seem more and more to ring true despite the presence of several industry heavies.
And what happens when you have a program attacking the file system through different disparate levels? An overview of what you're up to becomes impossible to attain. The file system interface - which by design is supposed to be so clean and simple - is suddenly confused and chaotic and ultimately downright dangerous.
And that's nowhere the enterprise people want to be.
Unix works pretty good. It's been around over thirty years. Why do the designer and 'user experience engineers' at Apple always think they know better?
Why can't they read the writing on the wall which states unequivocally they don't?
|