Space check before an rsync snapshot reports megabytes when tens of gigabytes are needed

Timeshift 25.12.4 on Linux Mint 22.3, rsync 3.2.7, target is an ext4 partition on a USB disk.

My snapshot filled the backup partition to the last byte and then died. Before starting it, Timeshift checked the free space and decided it needed 66.8 MB. The real figure was around 205 GB.

From that run:

[15:49:33] Checking if target drive has enough free space for a snapshot (RSYNC)
[15:51:58] Space required for snapshot: 66779801 (66.8 MB). Space available: 202426048512 (202.4 GB)
[18:47:03] exit_code: 11
[18:47:10] E: rsync returned an error

I cleared space and ran it again with a different exclude list. This time the snapshot finished, so I have both numbers from one successful run. Timeshift said:

Space required for snapshot: 63347684 (63.3 MB). Space available: 206079201280 (206.1 GB)

and rsync's own summary at the end of the very same run said:

Number of files: 1,611,373
Total file size: 88,130,209,464 bytes
Total transferred file size: 50,571,904,463 bytes
sent 50,667,223,241 bytes  received 14,101,887 bytes

Off by roughly a factor of 800.

The smallest reproduction I managed. One new 200 MB file, empty link-dest:

$ rsync -aii --recursive --verbose --stats --sparse --dry-run --link-dest=/tmp/t/old/ /tmp/t/src/ /tmp/t/new/
Total file size: 209,715,200 bytes
Total transferred file size: 209,715,200 bytes
Total bytes sent: 90
sent 90 bytes  received 22 bytes  224.00 bytes/sec

The number Timeshift uses comes from RsyncSpaceCheckTask.vala, where sent_bytes_regex matches sent ([0-9,]+)[ \t]+bytes[ \t]+received, and the captured value becomes total_size, which Main.get_space_needed_for_rsync_snapshot() hands back as the space requirement. That task runs rsync with --dry-run. A dry run moves no file contents, so the line it reads covers the file list. The regex is present in the binary Mint ships, and the 25.12.4 tag matches master for this file.

Main.vala:1414 only reaches the check when free space is below first_snapshot_size, so it applies in the situation where the disk is already tight.

A bit of history, which is why I am opening this separately rather than commenting somewhere. The check came in with #19 (22b0e16a) and closed #13, "Automated snapshots can fill up the disk". In December 2022 someone wrote under #13 that Timeshift kept filling the partition while believing it had 34.7 GB free. #221 is a machine that would not boot afterwards. #420 asks for a warning before the disk fills up, and #330 deals with the mess you are left in once it has. To me these look like the same thing, though I would not claim that about the btrfs reports.

I can run more tests on this machine if that is useful, with other exclude lists or a larger link-dest.

Start with RsyncSpaceCheckTask.vala, especially sent_bytes_regex and how its captured value becomes total_size, then trace Main.get_space_needed_for_rsync_snapshot() and Main.vala:1414. Run the minimal rsync dry-run reproduction from the report and compare its estimate with rsync's file-size and transfer statistics. Done means the space check reports a requirement consistent with the snapshot data rather than only dry-run protocol bytes.