Hi @kapitainsky,
I think you’re missing my point. Please re-read my posts above. I said nothing about providing functionality that manages free space dynamically. What I did say, and I’ll die on this hill, is that it is a major flaw that Kopia simply falls over if storage fills up. And when this happens, there is no emergency button to push to clean things up (eg, delete last N snapshots) and in fact it’s been noted that such a scenario has the potential to corrupt the entire backup repository. That is the part I am complaining about.
To use your UNIX analogy: I’ve been using Unix and Linux long enough that I remember when the filesystem would get corrupted if the host computer crashed or had a power failure. “That’s the user’s fault” the old-timers said. “They should use a UPS backup power supply”. But over time it was acknowledged that this was an unacceptable failure scenario and journaling filesystems such as ext3/4 and ZFS were developed. Similarly in the Windows world with the evolution of FAT to FAT32 to NTFS. And similar in the database world with the development of transaction logs and redo logs.
And to your point about restic et al, I see that restic has indeed solved my complaint;
Recover from no free space errors by MichaelEischer · Pull Request #3481 · restic/restic
And in the borg docs they call out that borg handles an out of diskspace condition gracefully:
If you run a backup that stops due to a disk running full, Borg will roll back, delete the new new segment file and thus freeing disk space automatically. There may be a checkpoint archive left that has been saved before the disk got full. You can keep it to speed up the next backup or delete it to get back more disk space.