[wp-trac] [WordPress Trac] #54582: Problem with deleting old files at the end of a core update when the filesystem is case-insensitive

[WordPress Trac]

#54582: Problem with deleting old files at the end of a core update when the
filesystem is case-insensitive
-----------------------------+---------------------------------------
 Reporter:  pbiron           |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  high             |  Milestone:  5.9
Component:  Upgrade/Install  |    Version:
 Severity:  major            |   Keywords:  needs-patch needs-testing
  Focuses:                   |
-----------------------------+---------------------------------------
 WP 5.9 updates the external Requests library (used by
 [https://developer.wordpress.org/reference/functions/wp_remote_get/
 wp_remote_get()], et. al).  As part of that update, a number of filenames
 have changed in case only, e.g.

 * wp-includes/Requests/IRI.php => wp-includes/Requests/Iri.php
 * wp-includes/Requests/Transport/cURL.php => wp-
 includes/Requests/Transport/Curl.php

 When updating to 5.9-beta1 via `wp-cli` on a system that uses a case-
 insensitive filesystem (not only Windows, but that's the most obvioous
 example) via the `wp core update --version=5.9-beta` command, all those
 files that have been renamed in case only get incorrectly deleted (in
 [https://github.com/wp-cli/core-
 command/blob/5d5cc4631381cad926b5c73841df31250cc8ff5e/src/Core_Command.php#L1352
 Core_Command::cleanup_extra_files()]) which results in PHP fatal error(s).
 This was discovered during the 5.9-beta1 release party, and an
 [https://github.com/wp-cli/core-command/issues/195 issue was created]
 against that wp-cli command.

 Core has it's own means on deleting files from previous releases, but it
 doesn't come into play until a major release package to built.
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /update-core.php#L21 wp-admin/includes/update-core.php] defines the
 `$_old_files` array that contains files from all previous WP versions that
 should be deleted by core after an update has been performed.  That array
 is not amended until just before the `major` version package is created
 (see [https://make.wordpress.org/core/handbook/about/release-cycle
 /releasing-major-versions/#dry-run Releasing Major Versions] in the Core
 Handbook].

 I've been experimenting and I think the exact same thing will happen when
 5.9 is is released and sites are updated via the Dashboard.

 To test this hypothesis I did the following on a Windows machine (with
 basically a WAMP stack):

 1. Installed 5.8.2
 2. Edited `wp-admin/includes/class-core-upgrader.php` and added `global
 $_old_files; $_old_files[] = 'wp-includes/Requests/IRI.php';` just before
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-core-upgrader.php#L172 line 172].  This simulates that file being
 added to the `$_old_files` array in
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /update-core.php#L21 wp-admin/includes/update-core.php] of the 5.9 release
 package.
 3. Added `define( 'WP_AUTO_UPDATE_CORE', 'beta' );` to `wp-config.php`.
 This allows core to update to 5.9-beta1 in `Dashboard > Updates` (without
 the need for wp-cli nor the [https://wordpress.org/plugins/wordpress-beta-
 tester Beta Tester plugin].
 4. Went to `Dashboard > Updates` and clicked on the `Update to version
 5.9-beta1` button
 5. When the update finished, I looked on disk and found that neither `wp-
 includes/Requests/IRI.php` nor `wp-includes/Requests/Iri.php` existed
 6. Went back to `Dashboard > Updates` (which causes
 [https://developer.wordpress.org/reference/functions/wp_version_check/
 wp_version_check()], and thus `wp_remote_get()`, to be called...resulting
 in a fatal error (`Fatal error: Uncaught Error: Class 'WpOrg\Requests\Iri'
 not found in ABSPATH\wp-includes\Requests\Requests.php on line 682`)

 One might thing that to avoid this problem, any files whose name case in
 case only just shouldn'd be added to `$_old_files`.  Unfortunately, that
 would be bad for sites with case-senstive filesystems, because then files
 with both filenames would exist on disk after the update (e.g., both `wp-
 includes/Requests/Iri.php` and /wp-includes/Requests-IRI.php`).

 To prove this to myself, I then did the following on a machine with a
 case-sensitive filesystem (centos 7):

 1. installed 5.8.2
 2. Added `define( 'WP_AUTO_UPDATE_CORE', 'beta' );` to `wp-config.php`
 3. Went to `Dashboard > Updates` and clicked on the `Update to version
 5.9-beta1` button
 4. When the update finished, I looked on disk and found that both `wp-
 includes/Requests/IRI.php` and `wp-includes/Requests/Iri.php` existed
 5. Rolled back to 5.8.2
 6. Edited `wp-admin/includes/class-core-upgrader.php and added `global
 $_old_files; $_old_files[] = 'wp-includes/Requests/IRI.php';` just before
 line 172
 7. Went to `Dashboard > Updates` and clicked on the `Update to version
 5.9-beta1` button
 8. When the update finished, I looked on disk and found that only `wp-
 includes/Requests/Iri.php` existed, as it should be

 As mentioned, I've only tested these hypotheses on Windows and linux
 (centos).  It would be great if someone could test on MacOS (in both it's
 case-sensitive and case-insensitive filesystem configurations)!!!

 What do I think should be done to solve this?  The "delete old files"
 routines in both core and wp-cli should check whether the filesystem is
 case-insensitive and, if so, not delete files whose names have changed
 only in case (note: the current [https://github.com/wp-cli/core-
 command/pull/196 PR] against wp-cli's `wp core update` command doesn't yet
 do this).  I've been experimenting with how to detect whether the
 filesystem is case-insensitive (hint: just checking the OS is **not**
 sufficient, for a number of reasons).  I'll add some comments about this
 after I finish opening this ticket.

 Related: #54546, #54547, https://github.com/wp-cli/core-command/issues/195

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54582>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform