restore: Don't hang on a filesystem that never preallocates

[msaggiorato]

Upstream submission candidate, off master, one commit.

The defect

The restorer reserves space for each file before filling it (upstream restic#2195, so that out-of-order blob writes don't fragment large files). On some sandboxed filesystems that syscall is accepted and never answered, and the damage goes well past a slow restore. Reproduced outside the original host — branch repro/preallocation-hang has a FUSE filesystem that never answers fallocate, plus the probes below:

• the restore stops at the first file needing data, leaves it at 0 bytes, prints nothing, and never finishes — the same stack as the production goroutine dump (createFile → ensureSize → PreallocateFile → unix.Fallocate);
• the kernel holds the inode lock, so pwrite, ftruncate and even unlink on that file block forever, and a blocked unlink wedges its directory;
• FALLOC_FL_KEEP_SIZE behaves identically, so no flag avoids it;
• the waiting thread sits in state=D wchan=request_wait_answer and ignores SIGKILL, so the process can never exit.

Why a deadline is not the fix

An earlier version of this branch put a 5 s deadline around the call. The reproduction shows that cannot work: by the time it expires, that file is unwritable and unremovable and the process is unkillable. Issuing the call is an irreversible commitment.

The change

Ask the filesystem first, then use it: preallocate a throwaway file whose name is unlinked before the call, from a process that exists only to ask, so a filesystem that never answers strands that process rather than the restore. The answer is kept per filesystem. Whether the call succeeded is not the question, only whether it came back — one that fails does so promptly, and both callers already tolerate failure.

Evidence it works

	upstream	with this change
restore on the hanging filesystem	never finishes	Restored 8 files/dirs (73.009 MiB) in 0:05, exit 0
preallocations the filesystem sees	one per restored file	one, for the throwaway probe file
checksums of restored data	files left empty	all match
process exit	unkillable (state=D)	clean
healthy ext4 (512 MiB file)	3 extents, fully allocated	3 extents, fully allocated, no warning

Open before this goes upstream

• the changelog points at placeholder pull/99999; restic wants prior discussion, and the real number replaces it
• whether the Co-Authored-By trailer stays
• it leaves a stranded probe process on such a filesystem, which is unavoidable — a reviewer may want that said differently
• related open upstream issues, same class of filesystem: Corrupted files when restoring larger Backup to Rook-Ceph. restic/restic#5543 (CephFS, restore corruption), "Invalid file size" errors when restoring Windows backup, on MacOS, specifically to an exFAT volume restic/restic#5480 (exFAT)

CI for this branch runs in #4, which adds the minio fix from #3, because master's own test workflow cannot get past Get programs.

🤖 Generated with Claude Code

https://claude.ai/code/session_017d5y4KNmm2N5ySPPH1H49Z