pbear wrote: ↑Thu Sep 12, 2019 10:49 pm
gm10 wrote: ↑Thu Sep 12, 2019 12:52 pm
It's actually a major annoyance that Timeshift does not check free space on the target device before creating a snapshot.
Agreed, that's either a bug or a very bad design decision.
Well, putting myself in the developer perspective thinking about how I'd fix it, on the first snapshot it's fairly easy because you know that all files will be written as they are. In fact there is a limited check in Timeshift but only when you first select the snapshot partition, not when you are actually doing the first snapshot. That must get fixed.
On subsequent snapshots, however, you do not even know how much data will be written until rsync has run through, so you'd have to do a --dry-run first to find that out, then check free space, then run rsync again for real. That would significantly slow the whole process down.
So from a design perspective I could actually accept not checking beforehand for performance reasons (I'd still do a nominal check for a hardcoded minimum free space amount like 1 GB or so). But what I cannot accept is not checking afterwards. Timeshift does roll back snapshots when you kill the rsync process while the snapshot is being created, but it does not roll them back if rsync fails, and that's clearly broken behaviour.
In addition you should probably perform a free space check even if the snapshot succeeded and warn the user if only very little space remains.
And to top this off, timeshift does not even return error codes, it always returns an ok status even when it completely failed. In my mintupdate I have to parse Timeshift's output to decide whether the snapshot was created properly, which is ridiculous.
So yes Timeshift's dev still has a few things left to do. Not sure how motivated he is though.
