Decay of the inheritance code.
NYKÖPING (Rixstep) – The original Rixstamp was created in one day. This update to Apple's MacOS Mojave 10.14.3 took two months.
The original was the product of careful planning, the type of planning that later used to write X-frame ( Xframe ). It's about outlining the goal goals in detail – down to the hours – and then sticking to it. Such a schedule also included times for coffee breaks and for lunch. And during a single working day of just under eight hours, it was completed. (X-frame / Xframe also went well.)
One can reasonably ask why. Why create an app whose only function is to set the timestamps on files? It's a very good question.
The first reason was that we saw Microsoft do it. Microsoft embedded OS version numbers in their timestamps. And if Microsoft did, we wanted to do that too.
Gradually, other purposes arose. Timestamp setting was an excellent way to detect intrusion into a file system ̵
Other reasons also discovered. Above all, it was an exposed programmable API – meaning you programmed it.
The original Rixstamp – shown here – incorporated by three time stamps. Note the availability of three stamps – Created, Modified, and Access. Also note the date range – from 1980 to 2107. Finally, note that it is still possible to set a millisecond field.
This original version of Rixstamp was completed. It can switch between UTC time and local time, recursively file files from a directory root, and also handle killing batch batches. It turned out to be very useful.
The Rixstep version of Rixstamp for OS was basically the same. In terms of layout, some things changed, but both enjoyed functional equivalence. Of course, both versions can explicitly set and retrieve a "default" stamp for all fields, here on OS X, exemplified by the push buttons & # 39; Get Default & # 39; and & # 39; Set Default & # 39 ;. & # 39; Recurse & # 39; was also explicit.
Between one and the other came Xstamp. While Rixstamp for OS X was written for a Unix file system (with only two time structures available), Xstamp was written for Apple's aging HFS, HFS, with up to five stamps, as shown below.
This actually presented a serious security issue for OS X users. One of the best defenses against malicious software is to monitor the most important timestamps. Of course, Microsoft's Windows had no defense – it's a Microsoft product, but standard Unix has this defense. The key field is what is called "changed" on Unix (or "ctime" in the programmer's lexicon). This field must only be modified from core mode. Changes in this field unambiguously point to something that is happening – which is perhaps incorrect – to the file system.
And while Microsoft didn't offer any such protection, one didn't think any better. Apple's OS X would – but didn't. For years there was a way around things using the old HFS APIs.
Check the & # 39; attributeMod & # 39; above. This is equivalent (was married to the Unix equivalent) on HFS. And while this should have been protected at kernel level in OS X, it wasn't – which means malware can still infect a Mac and completely cover its tracks.
Things changed with Tiger 10.4. Suddenly, the & # 39; attributeMod & # 39; / & # 39; ctime & # 39; out again. (Nothing is known about how Apple solved this, or why it was open before that, or why the question fields were not protected at core level, just at the user level. No, it's not good, so the suspicions are correct.)
To 10.14 and Dark Mode proved to be more problematic than expected. The other 53 (three and fifty) ACP apps went through a transformation over a two-month period, but this one lasted.
There were several reasons.
One: NIB was corrupt. How this happened is not known. Usually, NIBs are taken care of by the Interface Builder (IB) currently located in Xcode (XC). It took some time to track down the error and find a solution, and the source of error was found only after two full months. Yes, it's a good idea to keep backups of NIBs – something the original IB did. Of course.
Two: Apple wound up two key classes. One of these classes was used – with great panache – at NeXT trade show at the Unix expo in Stockholm. It's a great class. But again for some unimaginable reason, Apple decided to leave it. And it's a key class.
Apple does not reject the class – they have just left it in a state of disarray. The code still seemed – mostly – but cosmetically it was a blithering mess. It is immediately impossible to understand the Cupertino scenario behind one. If you are going to deprece, you do it clean (if at all – should be very discouraged). And if you're not going to deprece, then you don't leave the code in a mess, reminiscent of what happened to the default settings today.
Three: The IB mechanisms for linking the visual interface are blunt, unclear, and not at all intelligent, contradicting what is essentially a simple but brilliant idea. Often, there is only one way to do the easiest tasks, but in an overly involved way. Class variables for withdrawals are a vector, and there are also visual elements that occur actions. But they work in completely different ways. There is no indication of this in the IB interface. Even worse – the worst of it actually – is that today's keyedobjects files are not easily edited by hand, and the IB – since the transformation to XC – no longer provides the right interface that IB once had.  Put all this together and splash something else at the top: transfer the usual file paths to web-compatible URLs because Apple says it …
Why this is so, no one knows, and no one is trying to explain. But in a move reminiscent of Jim Allkin's attempt to sully Microsoft's DOJ case processing, all of a sudden, everything is online (but really it's not). Apple notes that their URL code works better internally, but this can only be because they spent more time on it.
Surely all the ISV code and time discarded by converting file paths to URLs, just to convert back again, over and over, should borrow a clue that someone was wrong wrong way along the way?
And that's still not enough, because these new "URL" variations on old "file path" methods are still inconsistent and incomplete. Sometimes there are correlated methods, sometimes not. One really wants to know what they are busy with One Infinite, or if they are even aware of what is happening and what is missing. They've probably spent far too much time to overhaul the old NeXT API, for dubious reasons, so why couldn't they finish the job?
In any case. Rixstamp for Mojave 10.14.3 is finally available, from tonight, and becomes # 54 to switch to Dark Mode ™. Setting the new APFS granularity in there will be a nice addition.
Apple's Unix file system now admits a "created" stamp, much like Microsoft. But of course Microsoft never came around to the inodes.