Simon Richter <s...@debian.org> writes: The order of operation needs to be > > 1. create .dpkg-new file > 2. write data to .dpkg-new file > 3. link existing file to .dpkg-old > 4. rename .dpkg-new file over final file name > 5. clean up .dpkg-old file > > When we reach step 4, the data needs to be written to disk and the metadata in > the inode referenced by the .dpkg-new file updated, otherwise we atomically > replace the existing file with one that is not yet guaranteed to be written > out.
If a system crashed while dpkg was installing a package, then my assumption has always been that it's possible that at least this package is corrupted. You seem to be saying that dpkg needs to make sure that the package is installed correctly even when this happens. Is that right? If so, is dpkg also doing something to prevent a partial update across multiple files (i.e., some files in the package are upgraded while others are not)? If not, then I wonder why having an empty file is worse than having one with outdated contents? Are these guarantees documented somewhere and I've just never read it? Or is everyone else expecting more reliability from dpkg than I do by default? Best, -Nikolaus
