The rollback temp file is named from the PID alone and created with File::create, which truncates an existing file. Two failure modes follow:
- A stale temp left by a crashed process with the same PID is silently truncated and reused.
- Two concurrent rollbacks in the same process share one path and race, so one can overwrite the other's snapshot.
Both matter because this file is the rollback snapshot — the copy used to restore the original after a failed compression. Losing it turns a recoverable failure into a corrupted file.
A fork of this engine in abitious named the temp with PID + nanos + a counter and created it with create_new (O_EXCL), so a collision fails loudly instead of truncating. That fork is now deleted in favor of depending on this crate, so the hardening is lost unless it lands here.
Suggested fix: add nanos and a process-local counter to the name, and switch File::create to OpenOptions::new().create_new(true).
The rollback temp file is named from the PID alone and created with
File::create, which truncates an existing file. Two failure modes follow:Both matter because this file is the rollback snapshot — the copy used to restore the original after a failed compression. Losing it turns a recoverable failure into a corrupted file.
A fork of this engine in
abitiousnamed the temp with PID + nanos + a counter and created it withcreate_new(O_EXCL), so a collision fails loudly instead of truncating. That fork is now deleted in favor of depending on this crate, so the hardening is lost unless it lands here.Suggested fix: add nanos and a process-local counter to the name, and switch
File::createtoOpenOptions::new().create_new(true).