Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Which version of SilentKnight and other apps do you need?

By: hoakley
6 September 2024 at 14:30

Every autumn/fall, the current version of macOS changes, and with it there are changes great and small that can affect the apps we run. If you use any of the free apps that I provide here, now is the time to check that you’re running the correct version to support both your current macOS, and any that you might aspire to in the coming months.

SilentKnight

Although most of my apps have auto-update mechanisms that inform you when their updates are available, there are some notable pitfalls that can lull you into a sense of false security. Most importantly, SilentKnight was upgraded to version 2 two years ago to ensure its compatibility with Catalina and later. Every few days I come across someone who is still using version 1 with a newer release of macOS and seeing incorrect results. If you use SilentKnight in any version of macOS from Catalina onwards, then please ensure that it’s updated to the current version 2.10:
SilentKnight 2.10 (Universal App for Catalina to Sequoia)

This is particularly important if you intend upgrading to Sequoia, because of the changes it brings in how XProtect is updated. If you’re still running 2.9 or earlier, then SilentKnight will give you incorrect versions for XProtect, and at worst could report a version of 0 (zero) as it might not be able to find XProtect at all.

Skint and SystHist

For the same reason, Skint should be updated to version 1.08:
Skint 1.08 (Universal App for Monterey, Ventura, Sonoma and Sequoia only)

systhist1181

SystHist lists full system and security update installation history, a task that invariably requires an annual update to cope with the quirks of the new version of macOS. If you’re aiming for Sequoia at some stage, ensure that you have updated it to version 1.20:
SystHist 1.20 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Writing Tools

Although Apple isn’t intending to release any of its new AI features in the initial version of Sequoia, 15.0, but is delaying them for 15.1, you might like to prepare for that by updating my rich text editor and PDF viewer in advance. Their latest versions should prove fully compatible with Writing Tools when they’re released.

DelightEd4

DelightEd is a Rich Text (RTF) editor with special Dark Mode features and support for interlinear text, and version 2.3 should work fully with Writing Tools:
DelightEd 2.3 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

podofyllin20

Podofyllin is a lightweight PDF viewer (without any editing capability, so it can’t alter original PDF files) and shows source code and more. Version 1.3 should work fully with Writing Tools:
Podofyllin 1.3 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

XProCheck, Nalaprop, Precize

Other recent updates you might have missed include the following.

XProCheck to check on XProtect Remediator scans completed and reported in the log:
XProCheck 1.6 (Universal App for Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Nalaprop for multilingual natural language parsing, now compatible with Writing Tools:
Nalaprop 1.3 (Universal App for Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Precize, which looks deep into files, bundles and folders to show their full size including extended attributes, provides macOS Bookmarks and volfs paths as enduring file references, and detailed information contained in Bookmarks and Aliases:
Precize 1.15 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Key points

  • For Catalina or later, particularly Sequoia, use SilentKnight 2.10.
  • For Sequoia in particular, use Skint 1.08.
  • For Sequoia in particular, use SystHist 1.20.
  • Older versions of those apps will give incorrect results when run in more recent versions of macOS.

What’s the time Mr. APFS? With a new version of Precize

By: hoakley
12 August 2024 at 14:30

It’s the middle of August, the time when, if you’re not an Apple engineer or third-party developer, you’re most likely to be on holiday. To help you enjoy that, today I’m going to engage you in a little game I call What’s the time, Mr. APFS?

To play along with me, all you need is a copy of the latest version of Precize, version 1.15, available from here: precize115
from Downloads above, from its Product Page, or via its auto-update mechanism.

Precize update

Thanks to some questions from applice, who should really be spending more time watching the Olympics than worrying about file systems, this new version of Precize comes with significant enhancements in its datestamp reporting. First, it now gives datestamps with decimal seconds, for those who want to be truly precise, and it adds two new time fields, for Attribute Modification, and Access, as shown in the screenshot below.

precize92

Once you’ve downloaded the Zip archive, unZip it where it is, and move the Precize app from its folder into one of your Applications folders (that ensures it doesn’t undergo app translocation). Keep the Zip archive it came in, as we’ll use that in the game, whose rules are simple: all you have to do is roughly guess the times in each of Precize’s datestamp fields, for different files and bundles.

What are the times?

APFS stores four datestamps for each file and directory in its volumes, and the four fields shown in this version of Precize correspond to those four datestamps. There is a fifth that the Finder can display, the date and time that an item was added to its current location. That’s not derived from the file’s attributes, but from directories, and isn’t shown in Precize.

The four datestamps are:

  • Created, taken from the create_time value, the time that this item was created, given as the clock time corresponding to an unsigned 64-bit integer giving the number of nanoseconds since January 1, 1970 at 00:00 UTC, disregarding leap seconds.
  • Modified, taken from the mod_time value, the time that this item was last modified, likewise.
  • Attr Mod, taken from the change_time value, the time that the item’s attributes were last modified, likewise. Those attributes include permissions, for example, and changes made to extended attributes should also update this value.
  • Accessed, taken from the access_time value, the time that this item was last accessed, likewise.

By default, APFS is relaxed over how it records the last of these. Some other filesystems are strict, and change the access_time value every time a file is read. Instead, APFS only updates this if its value is prior to (earlier than) the mod_time value. You can change this behaviour by setting an APFS volume’s APFS_FEATURE_STRICTATIME flag, for instance when mounting it by using a command like
mount -u -o strictatime

However, that’s not the default for APFS volumes. For example, inspect your Mac’s Data volume using the command
mount | grep '/System/Volumes/Data '
and you should see something like
/dev/disk6s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse, root data)
without any mention of the strictatime flag. List all mounted volumes using
mount
and you’re unlikely to see any using strictatime.

File datestamps

Open the new version of Precise, so it’s poised waiting for you to drop a file onto its icon in the Dock. Then take a screenshot, and drop that file onto Precise’s icon. What do you expect the four datestamps to be?

This is an easy one for starters: the four times should be very close, and almost match the time given in the screenshot’s name. The first two should be Created and Modified, the latter perhaps a thousandth of a second behind, reflecting the time it takes from creation of the screenshot file to completing the save. Next comes Accessed, when macOS opened the file to perform its animation of the screenshot sliding away. Last of all should be Attr Mod, recording when all its attributes such as permissions were set in its destination folder.

Now copy that file to another volume. What do you expect those four datestamps to be there?

Created and Modified should remain the same, as those are preserved when the file is moved around in local file systems. But Attr Mod and Accessed should record the time that file arrived on the second volume, reflecting its new attributes and its access for the copy.

Now try a couple of harder questions. Drop the Zip archive that contained Precize onto the running app’s icon. What do you expect those four datestamps to be?

All four datestamps should record times close to when you downloaded that Zip file from here. Just as with the screenshot, Created leads, closely followed by Modified, with Accessed and Attr Mod trailing. Note that they’re all four very recent, subsequent to its download to your Mac.

Unzip that Precize Zip archive again and drop the Precize app within it onto the running app’s icon. What do you expect those four datestamps to be?

Now the Created and Modified values are taken from that app when it left my Mac here, but Attr Mod should be more recent, and Accessed is likely to be older unless you have accessed the app bundle since then.

What’s the time, Mr. APFS?

All the best games involve learning. I hope these have shown you how those four datestamps are set and changed. In summary:

  • Software like the Finder, when copying between local volumes, also copies most of a file’s attributes, including Created and Modified datestamps for consistency, even though it creates a new file in the destination. Attr Mod and Accessed are linked to the copy event, though.
  • Software like browsers, when copying from a remote server to a local volume, don’t preserve the file’s attributes, so all four datestamps correspond to the local arrival and creation of the download.
  • Archives such as Zip files preserve most of a file’s attributes, and reconstitute its Created and Modified values to those saved when the archive was created.

As a final exercise, using Precize, determine whether copying files by AirDrop between Macs behaves conservatively like copying between local volumes, or resets datestamps as downloading from the internet does. Why do you think that Apple designed it to work that way?

Have fun!

❌
❌