File data integrity is one of those topics that never goes away. Maybe that’s because we’ve all suffered in the past, and can’t face a repeat of that awful feeling when an important document can’t be opened because it’s damaged, or crucial data have gone missing. Before considering what we could do prevent that from happening, we must be clear about how it could occur.

We have an important file, and immediately after it was last changed and saved, a SHA256 digest was made of it and saved to that file as an extended attribute, in the way that you can using Dintch, Fintch or cintch. A few days or weeks later we open the file and discover its contents have changed.

Reasons

What could account for that?

One obvious reason is that the file was intentionally changed and saved without updating its digest. Provided there are good backups, we should be able to step back through them to identify when that change occurred, and decide whether it’s plausible that it was performed intentionally. Although the file’s Modified datestamp should coincide with the change seen in its backups, there’s no way of confirming that change was intentional, or even which app was used to write the changed file (with some exceptions, such as PDF).

Exactly the same observations would also be consistent with the file being unintentionally changed, perhaps as a result of a bug in another app or process that resulted in it writing to the wrong file or storage location. The changed digest can only detect the change in file content, and can’t indicate what was responsible. This is a problem common to file systems that automatically update their own records of file digests, as they are unable to tell whether the change is intentional, simply that there has been a change. This also applies to changes resulting from malicious activity.

The one circumstance in which change in contents, hence in digest, wouldn’t necessarily follow a change in the file’s Modified datestamp is when an error occurs in the storage medium. However, this is also the least likely to be encountered in modern storage media without that error being reported.

Errors occurring during transfer to and from storage are detected by CRC or similar checks made as part of the transfer protocol. This is one of the reasons why a transfer bandwidth of 40 Gb/s cannot realise a data transfer rate of 5 GB/s, because part of that bandwidth is used by the error-checking overhead. Once written to a hard disk or SSD, error-correcting codes are used to verify integrity of the data, and are used to detect bad storage blocks.

Out of interest, I’ve been conducting a long-term experiment with 97 image files totalling 60.8 MB stored in my iCloud Drive since 11 April 2020, over five years ago. At least once a year I download them all and check them using Dintch, and so far I haven’t had a single error.

Datestamps

There are dangers inherent in putting trust in file datestamps as markers of change.

In APFS, each file has four different datestamps stored in its attributes:

• create_time, time of creation of that file,
• mod_time, time that file was last modified,
• change_time, time that the file’s attributes including extended attributes were last modified,
• access_time, time that file was last read.

For example, a file with the following datestamps

• create_time 2025-04-18 19:58:48.707+0100
• mod_time 2025-04-18 20:00:56.134+0100
• change_time 2025-07-19 06:59:10.542+0100
• access_time 2025-07-19 06:52:17.504+0100

was created on 18 April this year, last modified a couple of minutes later, last had its attributes changed on 19 July, but was last read 7 minutes before that modification to its attributes.

These can be read using Precize, or in Terminal, but there’s a catch with access_time. APFS has an optional feature, set by volume, determining whether access_time is changed strictly. If that option is set, then every time a file is accessed, whether it’s modified or not, its access_time is updated. However, this defaults to only updating access_time if its current value is earlier than mod_time. I’m not aware of any current method to determine whether the strict access_time is enabled for any APFS volume, and it isn’t shown in Disk Utility.

mod_time can be changed when there has been no change in the file’s data, for example using the Terminal command touch. Any of the times can be altered directly, although that should be very unusual even in malware.

Although attaching a digest to a file as an extended attribute will update its change_time, there are many other reasons for that being changed, including macOS adding or changing quarantine xattrs, the file’s ‘last used date’, and others.

Proposed strategy

1. Tag folders and files whose data integrity you wish to manage.
2. Back them up using a method that preserves those tags, such as Time Machine, or copied to iCloud Drive.
3. Periodically Check their tags to verify their integrity.
4. As soon as possible after any have been intentionally modified and saved, Retag them to ensure their tags are maintained.
5. In the event that any are found to have changed, and no longer match their tag, trace that change back in their backups.

Unlike automatic integrity-checking built into a file system, this will detect all unexpected changes, regardless of whether they are made through the file system, are intentional or unintentional, are malicious, or result from errors in storage media or transmission. Because only intentionally changed files are retagged, this also minimises the size of backups.

I don’t always hit the right keyboard shortcuts. Of those that I commonly get wrong, by far the most serious are Command-W and Command-Q in Safari. While the former just closes the frontmost window, the latter quits the whole app, and can lose the contents of online forms. Why can’t Safari show a confirmation alert before quitting, so I can cancel those unintentional quits?

No alert is going to stop you from using the wrong keyboard shortcut. All it will do is annoy you every time you want to quit Safari and press the correct keys. At worst, when you press Command-Q but intended Command-W, you’ll accidentally click on the wrong button in the alert and go ahead with quitting Safari. The error isn’t quitting the app, it’s pressing the wrong keys, and you’ll continue to do that unless you train yourself out of it, or change your practice to make it more robust.

Historically, keyboard shortcuts for quitting apps and closing windows have long been set as Command-Q and Command-W, as Q stands for Quit and W for Window. It’s unfortunate that the two keys are immediately adjacent, so making it easy to press the wrong one, particularly if you hunt and peck for keys rather than being a touch typist.

If you’re having this problem in Safari, then you’re most likely doing the same in other apps, although its impact there may not be as apparent. That’s because most other apps track changes made in open documents for this purpose, but that’s not something that Safari can do with web pages, as entering your own text within them is tracked by the remote web server, not the browser. This should be mitigated by any website that you’re entering text into: the server should either record those entries as you make them, or at least give you the option of saving them. That’s a basic expectation of accessible website design.

Solution

You may find it helpful to enable Ask to keep changes when closing documents in Desktop & Dock settings. Coupled with disabling the control below, to Close windows when quitting an application, that should bring more protective app behaviour.

It might seem tempting to try changing the shortcut for Quit, but as far as I can see, you can’t do that for all apps. Changing it for just one or a few introduces a major inconsistency, and only increases the risk of error.

The best way you’re going to address this is to remove its root cause, by not pressing Command-Q when you don’t want to quit Safari, and that requires you to close windows a different way. Readily available in macOS is the choice of:

• closing windows by clicking on their red Close button at the top left;
• using the Close command in the File menu;
• assigning a different key combination, and using that to close windows in all apps.

Although you don’t appear able to change the shortcut for Quit in all apps, you can for Close. Open Keyboard settings, click on Keyboard Shortcuts…, then on App Shortcuts at the left. Click on the + tool to add a new shortcut, and set that for All Applications, with a Menu title of Close, and a shortcut of something like Command-Shift-M. You may find Apple’s list of keyboard shortcuts helpful to ensure there are no conflicts. Whichever you choose, you should apply it consistently across all your apps. This keeps it standard and simple and makes it automatic.

Of those three options, my preference is invariably for the first, using the window’s Close button. That’s because it works independently of whichever window is at the front and ‘in focus’. With a little care checking which window you apply it to, it should be completely free of error. The disadvantage of both the Close menu command and its shortcut Command-W is that you might have a different window in focus, so sometimes you will end up closing the wrong one by mistake.

Training

Once you have chosen which to use, train yourself rigorously to use that, and that alone. When working with single-window apps you have the choice of using either, and you should consciously go through the process of thinking that through before deciding which control to use, to remind yourself of what you are doing and why.

The goal is to make closing windows and quitting apps, including Safari, thoroughly reliable processes, so you never make a mistake. That makes any warning alert superfluous, and you’ll then agree that it would only serve to irritate. That’s why better interface guidelines caution against displaying an alert unless there’s a compelling reason to do so, and not routinely whenever quitting an app.