Kakoune: .xyz.kak.3nG8VI files after session quit

[basbebe]

I had a session open and edited several files.

After the session quit (by reboot…), I now have files named like .xyz.kak.3nG8VI next to my original files.

Is there a setting to prevent this?

[Screwtapello]

No, Kakoune will always try to backup unsaved changes files if it's killed unexpectedly, such as by SIGSEGV, SIGTERM or SIGQUIT.

To avoid this, you have a few alternatives available:

• save modified buffers, or use :q! to close each running client
• quit the session with a signal Kakoune can't catch, like SIGKILL
• modify main.cc to not catch the signals you care about, and recompile

[basbebe]

thanks for clarifying this!

[lenormf]

Several users have been complaining about this side effect, lately.

While it's convenient to have this backup mechanism as a last resort against impromptu crashes, some might not want to have the editor litter their filesystem if they intentionally kill their sessions with SIGTERM, and don't care about the state of their buffers.

Maybe catching unexpected signals could stay (segmentation fault, bus error, abort etc.), but leave the rest be handled by third party backup plugins?

[mawww]

This only happens on buffers that have unsaved modifications, so we should not be littering too many files on users filesystem. That said, we could consider that receiving SIGTERM means the user does not care and not save backups in that case.

[githububub]

+1 for disregarding SIGTERM. It is slightly annoying to have to be aware of this type of litter and have to backtrack through directories to remove them.

[lenormf]

Note that the backup files aren't forgiven the second they're created, there's an autorestore functionality enabled by default that will get rid of them, once you re-edit the files that have a backup.

[lenormf]

Another thing I just noticed is that the backup will be removed once the restored buffer has been saved:

https://github.com/mawww/kakoune/blob/d79b0053239047525c1a8d659a7179c09dee47b8/rc/tools/autorestore.kak#L34-L45

This caught me off-guard, so now I'm thinking: maybe the backup should be removed as soon as it's been read?