Saving changes
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Contents
Overview
To save, or not to save …
There is no question that all document-orientated applications must at a bare minimum support autosave, in a clear, logical and intelligent manner.
There is a more burdensome question as to whether Apple’s idea of never needing to save at all is a good idea or a bad idea. Per consistency, the answer to this question is easier when the behaviour is identical across all applications. Microsoft Office implements “live autosave” (automatic save into the actual live document) in Microsoft’s typical manner of making Office behave differently to the rest of the system. The problems are two-fold:
- “Live autosave” in Microsoft Office only works when it wants to: some documents use it, and some do not, so the user is never clear on what is going to happen. While there are technical reasons behind this (for example whether or not the file lives in SharePoint), to a non-technical user these reasons are not necessarily apparent.
- “Live autosave” does not exist in most other applications, so users are burdened further with having to carry this unnecessary distinction in their head.
Assuming that “live autosave” is in use when it is not will result in lost work from forgetting to save periodically. Assuming that “live autosave” is not in use or simply forgetting that it exists (or indeed not realising it exist) will lead to files being overwritten. Excel has long had a bug where some documents recalculate (or some other irritant) on load and this causes the document’s dirty flag to be set, triggering a “live autosave” that resets the file’s modification timestamp when the user is merely examining the document.
“Live autosave” is not necessarily a bad idea, but it must be implemented with great care and consideration. Otherwise, all document-orientated applications must implement “classic” autosave. The latter alone is quite sufficient to survive reboots.
Manual save
Should Save be made a manual action, there needs to be a way to indicate when the active document contains unsaved changes. Existing implementations include:
- An asterisk placed next to the filename in the title bar or tab (used by many Windows applications)
- The active/inactive status of the Save button in the UI, so long as such a button is visible (it may not be)
- The appearance of the window’s proxy icon (solid for saved, faint for unsaved changes), introduced in Mac OS 8
- A dot placed in the window’s close widget (Mac OS X)
For example:
Applications should only be telling the window manager about the document status. How the unsaved changes state is shown should be left to the window manager to handle, to ensure that the behaviour is consistent between applications. For example, WordPad and Paint in Windows 10 do not indicate unsaved changes at all, neither does Adobe Photoshop 7.
Session saving
One of the underlying concepts of Apple’s pervasive “no-save” approach is that it is possible to sign out and sign back in and have all your applications and documents reappear just as they were prior to signing out. This means that reboots for updates can be performed without losing the state of your working environment.
Where possible, document-based applications should be capable of storing their state upon exit and restoring it upon launch. This state will include all open files and the position of each window. If file saving is to be made a manual action, a final autosave must be made of each file prior to the application’s exit and the files will be restored from autosave, to ensure that the user can back out of any changes made to the document that were not intended to be committed to disk.
Under these conditions, a modifier key or similar will be needed to close and re-open an application without restoring the state. Autosaved work will not be lost and auto-saved documents may still need to open automatically, depending on what standard means is chosen to notify the user of unsaved work.
For years, browsers have maintained crash-safety in the form of remembering what tabs are open and even the contents of form fields. Ideally, this concept would be extended as much as possible, starting with document-orientated applications, to accommodate from (for example) unexpected loss of power. Browsers themselves are likely to be exempted from the standard session-saving system but it may well be that a single state-saving mechanism can be used for browsers and other applications alike. Games will likely be exempted from session saving, although there is no reason why single-player games cannot also implement on-exit state saving.
See state for general notes on state.
Version history
“Live autosave” requires version history. Even without it, having a versioning file system is not a bad idea. See the MDFS page for notes on versioning.
Atomic save
As noted on the MDFS page, there is a viewpoint that application software (and by extension, the command line and user scripts) cannot tamper with the timestamps on files.
Some programs avoid data loss from a failed save by saving work to a new file, and then removing the old file and copying over the timestamps. Some Windows applications will delete the file first and then save it anew, losing the file’s creation timestamp; Windows works around this by copying the creation date from a delete file to a new file occupying the same name the new file is created within around 15 seconds of the deletion, which causes trouble if you intentionally remove and replace a file and the new file adopts the creation date from the old file; see The apocryphal history of file system tunnelling on the Old New Thing.
Clearly there needs to be a mechanism to save a file “atomically”: to write out a new version in a safe manner, which upon success, will make the new version the live version with the same creation date as the previous version.
Versioning alone is not sufficient, as “tunnelling” is still required during a create–delete–rename process to ensure that the new version is placed into the existing version chain instead of being seen as the first version of a new chain, with the old file simply deleted.
Opening a file on disk involves choosing the access mode: read, append and write. An additional mode of “new blank version” would accommodate programs that want to start a new version from scratch; it would be effectively a truncate to zero bytes but with the data written initially to a hidden temporary file seen only by the OS. Once the file handle is closed, if there is no versioning then the directory entry would be re-pointed to the new byte stream and the old byte stream simply de-allocated, and the modification timestamp updated.
With a versioning system, this mode would simply create a new version just as if the program had opened the existing file and written new data to it without first deleting it.
This new write mode reduces the need for “tunnelling” and for applications to need to tamper with file dates.