undefined

points

[-]

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".

by iifisnfiejf51 minutes ago|

parent|

[-]

> That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever

But it was, it was program other than vim (neovim) that did it. It deleted a file in a space that is meant for transient files that may be deleted at any time for any given reason and should not cause data loss, and yet it did because vim, in the first place, broke the file system’s contract.

Neovim shouldn’t have been messing there but at the same time there’s a much bigger culprit here in that vim shouldn’t have been storing this kind of data there in the first place. It was a broken system that broke even further. Simple as that.

by kazinator33 minutes ago|

parent|

[-]

NeoVim is a forked continuation of Vim.

Blaming Vim is like politicians blaming the previous administration.

by maxnoe2 hours ago|

prev|

[-]

> 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.

by 37 minutes ago|

parent|

[-]

deleted