Much Ado About a Trivial App

The decay of legacy code.

Get It Try It

NYKÖPING (Rixstep) — The original Rixstamp was created in one day. This update for Apple's macOS Mojave 10.14.3 took two months.

The original was the product of careful planning, the type of planning later used to write X-frame (Xframe). It's a matter of sketching out one's target goals in detail - down to the hour-by-hour deadlines - and then sticking to it. Such a schedule even included times for the coffee breaks and for lunch. And, in a matter of a single workday of a bit less than eight hours, it was completed. (X-frame/Xframe went about as well.)

One may reasonably ask 'why'. Why make an app whose sole function is to set the timestamps on files? That's a very good question.

The initial reason was we saw Microsoft do it. Microsoft embedded OS version numbers in their timestamps. And, if Microsoft did it, we wanted to do it too.

Gradually other purposes appeared. Setting timestamps was an excellent way to detect incursions in a filesystem - extraneously updated files stuck out like a sore thumb.

Other reasons surfaced as well. Above all, there was an exposed programmable API - meaning you programmed it.

The original Rixstamp - shown here - admitted of three timestamps. Note the availability of three stamps - Created, Modified, and Accessed. Note as well the date range - from 1980 to 2107. Note finally that it's even possible to set a milliseconds field.



This original version of Rixstamp was complete. It could toggle between UTC time and local time, stamp files recursively from a directory root, and also deal with drag-drop batches. It proved very useful.

The Rixstep version of Rixstamp for OS was much the same. In terms of layout, a few things changed, but both enjoyed functional equivalence. Both versions could of course explicitly set and fetch a 'default' stamp for all fields, here on OS X exemplified by the pushbuttons 'Get Default' and 'Set Default'. 'Recurse' was also explicit.



Between the one and the other came Xstamp. Whilst Rixstamp for OS X was written for a Unix filesystem (with only two time structs accessible) Xstamp was written for Apple's aging HFS, HFS admitting of a total of five stamps, as seen below.



This actually presented a serious security problem for OS X users. One of the best defences against malware is guarding the key timestamps. Microsoft's Windows of course had no such defence - it's a Microsoft product after all - but standard Unix did have this defence. The key field is the one called 'changed' on Unix (or 'ctime' in the programmer's lexicon). This field must only be modifiable from kernel mode. Changes in this field unequivocally point to something happening - something perhaps malfeasant - to the file system.

And whilst Microsoft offered no such protection - one didn't expect better - Apple's OS X was supposed to - but didn't either. For years there was a way around things by using the old HFS APIs.

Check the 'attributeMod' field above. This is the equivalent (was married to the Unix equivalent) on HFS. And although this should have been protected at kernel level in OS X, it wasn't - meaning malware could still sneak on a Mac and completely cover its tracks.

Things changed with Tiger 10.4. Suddenly the 'attributeMod'/'ctime' field was out of bounds again. (Nothing is known of how Apple solved this, or why it was open before that, or why the fields in question weren't protected at kernel level, only at user land level. No, that's not good, so the suspicions are correct.)

Moving to 10.14 and Dark Mode proved more problematic than expected. The other 53 (fifty-three) ACP apps went through a transformation over a two-month period, but this one held out.

There were several reasons.

One: the NIB was corrupt. How this happened is not known. Generally, NIBs are taken care by Interface Builder (IB) which resides today inside Xcode (XC). It took quite some time to trace the error and invent a workaround, and the source of the error was found only after two whole months. Yes, it's a good idea to keep backups of NIBs - something the original IB did. Of course.

Two: Apple deprecated two key code classes. One of these classes was used - with great panache - at the NeXT booth at the Unix expo in Stockholm. It's a great class. But, again for some unfathomable reason, Apple decided to abandon it. And it's a key class.

Apple didn't disallow the class - they just left it in a state of disarray. The code still worked - mostly - but cosmetically it was a blithering mess. It's directly impossible to fathom the Cupertino scenario behind that one. If you're going to deprecate, then you do it cleanly (if at all - should be highly discouraged). And if you're not going to deprecate, then you don't leave the code in a mess, reminiscent of what happened to the defaults system today.

Three: the IB mechanisms for tying the visual interface are obtuse, obscure, and not at all intelligent, contradicting what essentially is a simple but brilliant idea. Most often there is only one way to perform the simplest of tasks - but in an overly involved manner. Class variables to outlets is a vector, and so are visual elements to instance actions. But they work in totally different ways. There's no indication of this in the IB interface. Worse still - the worst of it actually - is that today's keyedobjects files aren't easily edited by hand, and IB - since the transformation to XC - no longer provides the straightforward interface that IB once had.

Add all this together, and then sprinkle something else on top: transmogrifying ordinary file paths into web-compatible URLs because Apple says so...

Why this is so, no one knows, and no one's going to attempt to explain. But, in a move reminiscent of Jim Allchin's attempt to sully Microsoft's DOJ proceedings, suddenly everything is the web (but really it's not). Apple do note that their URL code works better internally, but this can only be because they've spent more time on it.

Certainly all the ISV code and time wasted by converting file paths to web URLs, only to convert back again, over and over, should lend a clue that someone took the wrong fork in the road?

And that's still not enough, for these new 'URL' variants on old 'file path' methods are still inconsistent and incomplete. Sometimes there are correlated methods available, sometimes not. One really wants to know what they're up to at One Infinite, or whether they're even aware of what's going on and what's missing. They've certainly spent way too much time upheaving the old NeXT API, for dubious reasons, so why couldn't they at least finish the job?

At any rate. Rixstamp for Mojave 10.14.3 is finally available, as of tonight, and becomes #54 to go over to the Dark Mode™. Putting the new APFS granularity in there will be a nice addition.

Apple's Unix filesystem now admits of a 'created' stamp, much as Microsoft. But of course Microsoft never got around to the inode stuff.

See Also
Rixstamp: 1 January 1970

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.