Plugin Update deletes plugin and showing "could not delete old plugin" message.

[apedog]

I just came across this on my local machine (Windows).

I had a plugin directory open in vscode editor. I had also previously edited one of the files in that plugin (added error_logs in one of the functions for testing). I may or may not have had same file open with further unsaved changes (I don't know at this point).

In the Plugins page I clicked the "update now" in the plugin row (directory was still open in vscode).
The update resolved with a "Could not delete old plugin" error notice. However the plugin was removed and directory is left empty.

[SergeyBiryukov]

I also had this happen a few times when attempting to update a plugin while one of its files was opened in an editor.

I believe this is working as intended though, since the OS doesn't allow for removing a directory with a locked file. What would be a suggested fix here?

[apedog]

I'd like to start off by saying that this is not a major issue for me. I ran across this edge-case and figured I'd post a bug report - for the record. This did not impede my work in any meaningful way. Maybe it's an unimportant edge-case, maybe it touches upon a deeper implementation problem - I honestly don't know.

Nonetheless, if this issue is to be addressed:

1. At the very least the message "Could not delete old plugin" is wrong. The old plugin was deleted. Empty plugin directory was all that remained.

2. As for "expected" behaviour - my expectation would be that if the update failed, I'd still have the old version in place, and not have the plugin vanish unceremoniously. Or at least some indication that a plugin was removed due to an error (and what the plugin's basename was - allowing the user to troubleshoot). As it stands upon Plugins page refresh - everything appears normal sans the deleted plugin.

I've no idea as to the amount of work that would go into fixing this. Just laying it out.

[pbiron]

I've also experienced this a number of times on my local dev machine. Also happens (at least in Windows), if you've got a shell open in the plugin directory (or one of it's sub-directories). In fact, probably 95% (or more) of update failures I've experienced over the years on my local were the result of this.

The only way I can think to prevent it would be to check whether any of the files in the directory were opened before starting to try to delete them. However, I don't think there's a reliable way in PHP to check this (that works across OS's and web server configurations).

@apedog Do you remember what version of PHP you were running when this happened to you? I mention that because I just noticed that the PHP manual for ​unlink() now says that as of PHP 7.3.0:

On Windows, it is now possible to unlink() files with handles in use, while formerly that would fail. However, it is still not possible to re-create the unlinked file, until all handles to it have been closed.

[apedog]

Replying to pbiron:

Do you remember what version of PHP you were running when this happened to you?

Nope. Sorry.
I see that I've installed PHP 7.4 almost exactly 12 months ago. And this ticket is from 11 months ago.
But it did take me a while before I fully migrated my environment from 7.2
So this is exactly from that time :(

[justinahinon]

I assume this mostly arrives in Windows environment?

I've tried to reproduce the issue on this setup:

macOS Big Sur 11.1
WordPress 5.7.2
Theme: TT1
PHP 8.0.0

I've made many tests with only the plugin "Custom Post Type UI" ​https://wordpress.org/plugins/custom-post-type-ui.

I've uploaded the version 1.9.0 and updated to the latest 1.9.1 in these scenarios:

• A plugin file opened
• A plugin file opened, edited, and saved
• A plugin file opened, edited, and not saved
• A terminal opened in the plugin plugin directory

I all these cases, the update works correctly.

[jgangso]

The method \Plugin_Upgrader::delete_old_plugin() which is responsible for deleting the old plugin does its job by recursively listing files and removing them one by one. In the end it checks if the directory got removed as a whole. If it didn't, it returns false.

This becomes an issue f. ex. with NFS mounts where the removed file is replaced with a temporary .nfsXXXXXXXXX file if the file has a write-lock on it (for any reason).

From the file systems perspective it's fine. The file system will take care of removing the .nfsXXXXXXXXX files whenever the locks are released.
Wordpress in turn considers this as a failure and terminates the process.

Just writing it here for the note. I don't have a solution at hand, but we'll need to look at this closer in our project, so I might update/comment on the issue later on.