Rust lacunae [LWN.net]

Rust lacunae

Posted Jun 11, 2021 9:52 UTC (Fri) by james (guest, #1325)
In reply to: Rust lacunae by ncm
Parent article: Rewriting the GNU Coreutils in Rust

When bugs do trap, such as array indexing errors, the resulting panic cannot be presumed to clean up properly before exiting.

OK, I'm curious: what sort of clean up would be reasonable for a coreutils utility beyond just dying?

to post comments

Rust lacunae

Posted Jun 11, 2021 14:24 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

One that I can think of is the mv command. If anything goes wrong it is nice if mv deletes any temporary copy it had made in the process of moving a file across filesystems.

Of course, if the cleanup is truly important than you cannot implement cleanup using exceptions, panics, or error return codes. There is just no way to be sure that the process isn't killed, so for thorough, reliable cleanup it needs to fork() and have the parent wait for successful completion. If the child fails the parent can clean up. That works for OOM Kill, segmentation fault, illegal instruction and other failures.

Rust lacunae

Posted Jun 13, 2021 13:52 UTC (Sun) by jezuch (subscriber, #52988) [Link]

Well, nobody's safe from SIGTERM, but other than that the Rust devs go out of their way to make sure that panics unwind everything safely. There were major features held up just because they could not guarantee this.

I myself would be completely satisfied if mv did not clean up completely after it was killed by an unmaskable signal. After all, it seemed like this was the intent of the killer!

Rust lacunae

Posted Jun 13, 2021 14:14 UTC (Sun) by james (guest, #1325) [Link]

If anything goes wrong it is nice if mv deletes any temporary copy it had made in the process of moving a file across filesystems.

I've no idea if any version of mv actually does this, but I understand it's possible to open an un-named, unlinked temporary file and write to it, then when you've finished create a link to the file (meaning it has a name and isn't temporary any more), fsync as necessary, and then delete the original file. If the program crashes before the file is linked, then Linux will automatically delete it.

Once the file is linked, you've got a full copy where you want it. Deleting that copy is not obviously the right thing. Deleting the original copy is, but the program crashed when it tried to do that.