Update script fails with `Directory not empty` error

[skManux]

Current Behavior

by using the auto-updater script sudo bash -c "$(curl -fsSL https://pelican.dev/updatePanel.sh)", it asks for some information (like the directory of the panel, the user and group owner of the files, wether to backup or not, etc...).

it actually backups everything correctly in the right folder, but when it comes to deleting old data, it deletes everything (except the backup folder) and after that it throws this error rm: cannot remove '/var/www/pelican/storage': Directory not empty and exits.

i had to update the panel manually and copy the backup data manually via cli to the target folders.

Expected Behavior

it should automatically backup data, delete folders, reinstall new panel and use backups to restore databases and get everything up and running automatically.

Steps to Reproduce

just run the command for the auto-update script as shown in the website at https://pelican.dev/docs/panel/update/.

please, add some dry-runs or people that are not practical to using linux or the cli could easily break everything and loose their data if this issue is not fixed asap.

Panel Version

update ver: 1.0.0-beta38

Wings Version

not relatable

Games and/or Eggs Affected

No response

Docker Image

No response

Error Logs

Is there an existing issue for this?

• I have searched the existing issues before opening this issue.
• I have provided all relevant details, including the specific game and Docker images I am using if this issue is related to running a server.
• I have checked in the Discord server and believe this is a bug with the software, and not a configuration issue with my specific system.

[notAreYouScared]

This happens when someone visits the panel while you're attempting to do the update, and a file gets created. Nothing we can really do to prevent it... We should use php artisan down but that does nothing when we are deleting everything, including the lock file the command creates...

[skManux]

maybe you could test the folder via a dry-run (or run find $install_dir/storage) and look if there are important files.
if there are only logs, proceed via rm -rf.

(that's just a suggestion. you surely know the code better than me, but this could be an option if the correct failsafes and checks are used)