> It's trivial to implement and much easier to use.

...unless you opened the document from a network share or removable media. Or serialization takes a long time. Or the storage device is slow. Or you don't have write permission in the file's original location and have to pull a potentially large file from somewhere to persist changes to some local position. Or the local storage device is full.

A "always save" mechanism would be best on a system that supported copy-on-write, network-aware links, and automatic file versioning to make writes super cheap. On actual real world systems that currently exist these mechanisms don't really exist or aren't universal so "always save" is fraught with difficult to handle edge cases.

You don't have to write in the same directory as the original file (and you definitely don't want to overwrite the original file). Original vi (and nvi) keeps the working copy below /var/tmp. If you can't write there, you have bigger problems.

(just be consistent from which host you modify a file from ;-}

Writing to /tmp is great if your file is loaded entirely in memory. Not all programs do that for a variety of reasons. Like I said, it's the tons of edge cases that make "constantly save" problematic and far from a trivial feature.

/tmp often is a RAM based file system. Not the best destination for data intended to be permanently saved. (n)vi is primitive enough to insist in copying the whole file (usually not a problem with files meant to be edited interactively), but nothing stops a more sophisticated program to store only changes (transactions) and consolidate on request. Most software, certainly all interactively used, ought to be "crash-only" software [1].

[1] https://www.usenix.org/conference/hotos-ix/crash-only-softwa...

There have been a lot of scenarios where blowing away everything since the last save and reverting to known-good via the Open command has saved my ass.

The solution I think works best is to flash/blink the Save button when a file has changed. And ask them to save when they leave. Then, the user is more easily reminded to save when they feel it is most appropriate to do so, but is not compelled into saving and can revert to a previous version if they like.

It was even better working on a system that versioned files automatically so programs didn't need to re-implement these sorts of wheels continually.

Dave Cutler was right.

Only a minority of programs need that functionality. Databases and everything which implements transactions or version control itself, certainly don't. Neither all the temporary files, e.g. a compiler creates. If version control of your configuration files is external to the host (e.g. if some configuration management system like puppy, chef, etc. is used) then it's get in the way as well.

Dave Cutler was wearing his marketing hat when he claimed that such functionality belongs in the file system code. It would be nice, if it were in a library all interested applications could easily link to though.

I essentially have versions for all my files because of Apple’s “Time Machine” backup system. There’s the external drive at my desk and there’s also the cache of recent changes it maintains in free space on the local drive.

Both of these have saved my ass in the past. I don’t care if it’s actually part of the file system, but it sure as hell belongs somewhere in the OS IMHO.

> Databases and everything which implements transactions or version control itself, certainly don't.

Why should programs implement these themselves? It should be part of the OS.

I don't think you can get Oracle, IBM, etc. to agree on how a database ought to be implemented. It clearly depends on the use case as well. More fundamentally one can argue, that what can be implemented in userspace ought to be implemented in userspace (for security and maintenance reasons alone), rather than the kernel. And what good does a db do in a compute node?