That’s the one I’m talking about. The left-most button is the automatic update, the button to its right downloads the entire install instead of just the changed files.

For those who can use the automatic update, maybe they are receiving a smart only-update-the-files-that-changed. I wouldn’t know, as I’m stuck doing it manually. I suspect that if the only a few files have changed and someone complains that “it completely stripped away all of my modifications that I had coded in” then either all the changes that person made was in the few files changed or all the files were refreshed on the automatic update.

I haven’t made any core changes, however, since I suspect automatic updates are brute-force instead of incremental-based, the manual update would be safer for those who have made core change edits and want to preserve them, but a list of changed files makes the manual update go faster.

We’ll see how it goes next update. If the list of changed files isn’t posted at the time of the update, I’ll be going through the same process of hunt-by-date.

Interesting wp-includes/js/swfupload/plugins/swfupload.speed.js
doesn’t compare differently using Beyond Compare even though it has a newer date and a different size.

I noticed this too. When I diff’ed a clean 2.8.6 directory against my older 2.8.5 it looked like one of the two files had mac line endings (^M). file confirms that the two files do indeed have different line endings. Paste from my terminal:

The Tools->Upgrade replaces all core files. If you modify core files, including wp-content/themes/default and wp-content/themes/classic, those changes will get overwritten.

This is why the list of changed files is important to people who don’t want brute-force updates. Maybe in the future the auto-update method will be more agile, until then – manual update is the best answer for the person who started this thread.

This is why the list of changed files is important to people who don’t want brute-force updates. Maybe in the future the auto-update method will be more agile, until then – manual update is the best answer for the person who started this thread.

I disagree. The best answer for the thread starter is to create and use a new theme based on the default theme instead of editing the default theme in place. Also to ensure backups are taken every time a change is made that you cannot afford to lose.

That’s the best advice for the thread starter. The best answer would be to make WordPress updates agile, as currently it can cause data loss for no good reason, except perhaps to scare the user into making backups. While backups are always best practice, forcing the user to do so because the system proceeds with a reinstall instead of just an update isn’t the best system. As a system grows in complexity, it would be nice if that complexity saved its user from doing more mundane tasks.

While it’s always best practice to make backups, imagine having to backup your user data, format and reinstall every time your computer’s operating system needed a security update. People tend to trust the computer to keep their changes safe without understanding exactly how the computer operates. That seems to be what happened here.