You think they put that notification there to annoy you? No, it's because of possible data loss and/or system file corruption if you turn off the power while the system files are being patched. Splash screens exist because the program is loading. If you want the functionality of Paint, or Notepad, open those instead. If you want Photoshop, you open Photoshop, and it takes a while to load because it is gigantically complex. If you want it to load faster, buy a new computer.
Surely Windows updates are applied via some sort of transactional system that can be rolled back and re-attempted if the process fails for whatever reason?
Having a power cut during a Windows update shouldn't result in a completely trashed system.
Surprisingly, NTFS does allow for transactions [1] and this feature is implemented since Vista, while as far as I know, HFS+ on Macs has no comparable feature. Therefore what you say may in fact be true.
I'm curious if cutting the power on a Mac while it's moving files into place will break a software update, or if the whole package receipt mechanism prevents that from occurring.
I'm not sure even transactional NTFS would protect you in this case. From the wiki link:
Transactional NTFS is implemented on top of the Kernel Transaction Manager (KTM), which is a Windows kernel component.
Because this is implemented on top of the kernel itself, if you have brought down the kernel in order to update files within said kernel, you likely are not going to be able to leverage the transactional rollback. You might able to do a system restore, if you boot from CD, but breaking your kernel is not an easily recoverable situation. I suspect there are actually safegaurds in the update procedure which protect against this situation, but things can go wrong and it is really not something you want to have to rely on.
I was thinking more of having a transactional system within the update software itself independent of anything on the filesystem.
Something like this:
1. Download all compressed archives that are required for the update from the update website and unzip somewhere.
2. Check the package manifest and figure out which files need to be changed/added/deleted.
3. Write a flag somewhere on the boot drive that says the update process has begun and which files will be altered.
4. Make copies of all the files which will be changed.
5. Work through the update process by modifying or overwriting the copied files with the contents of the update archives.
6. Temporarily suspend the scheduler so the update process is the only thing running and release locks on all of the files which will be changed.
7. Work through every file that needs to be changed and link the filesystem reference from the old version to the new version whilst keeping a copy of the old version.
8. At every stage in 7 mark in a log which references have been updated.
9. Mark a flag to indicate that the update process has been completed, either resume the scheduler and re-instate locks or force a restart of the OS if necessary.
When the system next starts up as part of the bootup process it can check if both the transaction start and finish flags are set.
If the start flag is set but not the finish flag then it knows that an update failed so it can roll back by re-linking to the old versions of every file (reading the logs to know which files to re-link) and setting the start flag back to 0 so it can try again.
If the update was successful then it can delete the old files if the disk space is needed or keep them around in case there is an issue later which required a restore.
In regards the kernel example, my Linux install actually keeps old versions of the kernel on the system so that if a kernel update breaks something for whatever reason it is still possible to boot the system from the previous kernel. I imagine Windows and OSX do something like this , although possibly more transparently.
Note: This is what I could think of off the top of my head, I'm sure it's not a perfect way of doing it but it demonstrates the idea.
I don't know if it follows those exact steps, but in the last few months I had several times a machine crash (flaky power supply) in the middle of various Windows Updates and it always recovered pretty well. It looked to this outsider like there was some sort of journalling going on.
On HFS+ on OS X, most file writing is done atomically, by writing to a temp file and atomically switching the (conceptual) data pointer of the target file, aka FSExchangeObjects. It's common to end up with some of these temp files in ~/Library/Preferences, ending in .plist.asdfx, when the process was interrupted (so the original remains untouched).
This can be done for directories too - make a new one, write changed files and hard link unchanged ones, then FSExchangeObjects. Obviously this scales linearly with the number of files in the directory, so it's not perfect. I'm not sure if / how any of this is used for system updates, though.
