Hacker News Reader

Comment by skissane | Hacker News Reader

If this "save a backup file" functionality was built into the OS, instead of having to be redone by every application, this probably would never have happened – it is much harder to do the wrong thing when you are just calling an OS API than when you have to implement it all yourself. And if the OS API is implemented wrong, you can just change the OS API, instead of having to change every application.

I like how Vim uses swap files to warn you if you are editing a file you already have opened (or have autosaved data from a previous crashed execution) – but it only works for Vim, if you open the file in another editor you don't get the warning. If that functionality was in the OS instead, it could easily work cross-application.

View on HN

While not quite as good, there is NILFS: https://en.wikipedia.org/wiki/NILFS

I wasn’t aware of it. Fascinating

Unfortunately it's deprecated, I have used it for around an year for my home as a test, the idea is good, the implementation not much:

- the cleaner daemon is damn slow, so on write-intensive (as a modern WebVM profile dir, improperly named browser for legacy reasons profile dir) you'll easily end up in a filesystem full, and recovery is not that easy;

- navigating through the write history is manual, a manual mount of a snapshot that might disappear while you actually go through a bunch of them, so you need to mark them to stop garbage collection, mount them, diff/see the change of something you are interested in etc.

No shiny meld-like UI is there, there were some project in the past but so long abandoned that I've just found references to them, not even their code. Nowadays the sole Linux log-based fs is Samsung f2fs, witch is far less developed than nilfs2, to a point you can't even go through the write history. The sole good log-based fs I know is DragonFlyBSD Hammer, witch is "a better zfs" but being a DragonFly-only show with very little devs it's not really useful if you are outside the HPC world.

Personally these days I have zfs with auto snapshot service well backed by ZnapZend to sync data to a homeserver backup, it's not write()-triggered but time triggered so going through history is less useful, but as a raw protection against accidental disasters it's generally enough, zfs diff is not much detailed (just tell about changed files) but might be of help, snapshots are auto-mounted typically under the volume root in a .zfs/snapshots/$snapName dir so reasonabily easy to traverse with meld, a file manager etc to directly grab some files.

Unfortunately since the '80s no one except for SUN (zfs) have done much on generic data storage/file storage side...

You don't really need that much functionality, a copy-on-write filesystem with fine-grained access to historical data. Once you have that, you can easily access the old version of a file and that is probably 90% of the functionality that you need without many changes to the software (regular automatic saves and ability to access old versions from the program itself).

While there are a number of copy-on-write filesystems around (ZFS, btrfs), most of them don't have fine-grained access to historical data, but only through snapshots. One exception is them HAMMER fs from DragonFlyBSD [1], though I don't if this is still true (HAMMER2 seems to be quite a different beast)

[1] https://www.dragonflybsd.org/docs/docs/howtos/howtorecoverda...

Sadly that’s not what copy on write means. When you have file a and you copy it to file b. COW means the copy b will only be truly materialized once you write something to it/edit it. Before that, file b will be aliased to file a.

If you have file A and a make a snapshot of it, let's call it A@2022-04-01-12:00, you have now two different files pointing at the same blocks.

If you write to one of the blocks of A you will not overwrite any data of A@2022-04-01-12:00 because the new data will be saved to a different block. I would call that copy on write.

I admit that the description is not perfect because it doesn't always apply (like in the example you make), but I couldn't come up with a more appropriate description and for the discussion at hand I thought it was quite apt.

Also, for what is worth, Wikipedia seems to agree with me [1]

[1] https://en.wikipedia.org/wiki/Copy-on-write#In_computer_stor...

VMS!

Files-11, specifically.

https://en.wikipedia.org/wiki/Files-11

The main feature of VMS which seems relevant here is file version numbers–it is a great idea, and it is sad more mainstream operating systems haven't copied it (if only Dave Cutler had taken that VMS idea to Windows NT... if only RMS' plan, announced in the GNU Manifesto, to include a file versioning filesystem in the GNU system had panned out...)–but I don't think it fully addresses the issue of editor autosave/etc:

(1) File version numbers are great to make a backup of the old file on saving, not so relevant to creating an autosave of a modified editor buffer / open document / etc. You generally want autosave to not create a new version of the file you are editing, because that would make your changes visible to other applications/users, and you haven't decided yet whether you want to "commit" your in-progress changes to the actual file.

(2) Doesn't really address the case of warning you that you (or somebody else) has the file open in another editor, or that you have recovered changes from a prior editing session. I know VMS has some file locking features that might help with the "warning" part, but other platforms do too. As far as I know, VMS still leaves it up to each app to build a sensible UI around those capabilities, rather than providing something built in to the OS.

We already have tools for this. Important work should be in version control and application authors who want more out of open have sqlite. People need open/read/write to work with the file directly and I don't want shell tools scattering backup files everywhere.

Reply on news.ycombinator.com