alt Hacker NewsThe lifetime of files in ~/.cache/ is the same as what the FHS documents for /var/cache [0]:
> Application cache data. Such data are locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. The cached files can be deleted without loss of data.
Meaning: the persistence of such files is not guaranteed across application restarts. If vim (and also neovim) had intended for the undo files to outlive the program, the files should have been put in ~/.local/state instead -- as also explicitly documented by the XDG [1]:
> [XDG_STATE_HOME] may contain: [..] current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
[0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#...
[1] https://specifications.freedesktop.org/basedir/latest/#varia...
Replies
That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever, but a targeted hit from the application itself on files known to be persistent undo.
You just can't point the finger at file system standards, or shoulda-read-release notes or whatever.
There is no such thing as "by mistake, we historically stored persistent files in a directory with 'cache' in its name, contrary to a popular standard, so that makes it okay to trash them now".
> The application must be able to restore or regenerate the data
That's a break of the contract then, right? The application was not able to regenerate or restore.
Cache is the wrong place for a persistent undo file.