I have developed a theory for how this happened. Let me describe how the old and new methods of emptying the share work.
There are two pieces used to remove the contents of the .Recycle.Bin folder. The UI passes the share recycle bin reference to a script that does the actual removal.
Old way:
When the Share empty button was pressed the UI passed the share path to the script that removed the .Recycle.Bin contents. The script appended the '.Recycle.Bin' to the passed in path to the share. In your case the UI would pass in /mnt/user/SHARENAME and the script would append the .Recycle.Bin folder to the share path to make /mnt/user/SHARENAME/.Recycle.Bin which is the proper folder to the recycle bin contents.
New way:
A symlink is created for each share with recycle bin contents at /mnt/RecycleBin. This was originally created to make the Unraid file browser work. For several reasons, I decided that it would be better for this to be used for the UI for browsing and share empty functions. So now the UI passes in the symlink to the share recycle bin directly to the script and the script just removes the recycle bin contents from the share symlink path directly because it already references the share .Recycle.Bin. The passed share recycle bin path is then /mnt/RecycleBin/SHARENAME which is the correct path to the .Recycle.Bin folder.
Your sequence of operations as best as I can tell is:
- Browse to the recycle bin UI to look at SHARENAME recycle bin contents and remove a deleted file.
- Decided to check for an update first and see if there is an update.
- Update the recycle bin plugin.
- Go back to the recycle bin UI and empty the share recycle bin. The old UI is cached?
I am not an expert at how browsers cache web pages, but I think that the recycle bin UI was not refreshed to the new plugin version. The script would have been updated, but the UI web page may not have been. So you have the old method of the UI and the new method of the script. The old method UI would then pass /mnt/user/SHARENAME to the script but the .Recycle.Bin would not be appended as in the old way of doing things and the /mnt/user/SHARENAME contents would be removed because the script expected it was a symlink to the /mnt/user/SHARENAME/.Recycle.Bin folder.
I know this is a stretch, but I could see how it could happen. What I've done in the latest version is to block removal of the share recycle bin contents if the path is not /mnt/RecycleBin/SHARENAME passed in to the script and log an error.