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.