updater constantly fails to remove folders

[2019-05-10]

[✔] Check for expected files
[✔] Check for write permissions
[✔] Create backup
[✔] Downloading
[✔] Verify integrity
[✔] Extracting
[✔] Enable maintenance mode
[✔] Replace entry points
[ ] Delete old files ...PHP Warning: rmdir(/home/nextcloud/updater/../lib/l10n): Directory not empty in phar:///home/nextcloud/updater/updater.phar/lib/Updater.php on line 862
[✘] Delete old files failed
Could not rmdir: /home/nextcloud/updater/../lib/l10n
Update failed. To resume or retry just execute the updater again.
$ ~/updater]$ php updater.phar

The web updater always fails to remove a bunch folders, making each update to a hours long experience of removing folders manually, restarting updater again, removing folders from updater folder (why aren't files just copied and the updater folder deleted in full at the end?), fixing missing files the updater always looses.

Today I tried the command line updater, since I understood the web updater may run into timeout issues.
But here I am again.

"Update failed. To resume or retry just execute the updater again."

executing the updater again, starts everything again, including backup which is not necessary after the first time (and in fact will probably result in a useless backup).

If indeed even the cli updater suffers from timeouts due to too long running operations, starting from scratch over an over again ist not going to help, instead it should remember the last step and proceed from there.

shared web server w/o any way to change settings
FreeBSD 11.3-RELEASE-p6

[kesselb]

Added the needs info label because the issue template is missing. For some reason the updater is not able to remove the folder. I would probably check the permissions.

[2019-05-10]

permissions are corret and always have been.
from all I tried it's most likely a timeout issue -- replacing

$state = rmdir($folder);
if($state === false) {
  throw new \Exception('Could not rmdir ' . $folder);
}

with

$state = rmdir($folder);
if($state === false) {
  $state = rmdir($folder);
    if($state === false) {
      throw new \Exception('Could not rmdir ' . $folder);
    }
}

and commenting unnecessarily repeated steps like backup, download, integrity, extract finally made it working -- more or less.
The updater needs to be able to work with shared hosts where limits are rather strict.
At a minimum it needs to remember the last step and continue from there -- not repat them over and over again, always causing the timeout to happen again and again, files going missing since having been deleted in the previous step and so on.

[2019-05-10]

For those like me desperately looking for a workaround:
extract updater/update.phar as per
#145
and edit updater/lib/UpdateCommand.php (switch with updater steps) and updater/lib/Updater.php (rmdir stuff)
see link for how to proceed

[2019-05-10]

After some hesitation I updated from 17.06, which gave me all those troubles, to 18.04

• unpacked updater.phar
• edited lib/Updater.php to retry rmdir(), leave the download, log non-deletable folders from extracted update zip instead of throwing an exception (why does it do that anyway? the extraced zip is to be deleted in any case!)
• in lib/UpdateCommand.php successively comment the steps 3, 4, 5 in

$this->updater->startStep($step);
switch ($step) {
case 1:
$this->updater->checkForExpectedFilesAndFolders();
break;
case 2:
$this->updater->checkWritePermissions();
break;
case 3:
$this->updater->createBackup();
break;
case 4:
$this->updater->downloadUpdate();
break;
case 5:
$this->updater->verifyIntegrity();
break;
case 6:
$this->updater->extractDownload();
break;

before reattempting the update, if the errors about non-deletable folders occurs.
Attached the two files I modified.

I think, the updater should
a) always re-start from the last step, not from the top
b) keep the downloaded zip and the extraced folder until the very end
c) not attempt to delete any files/folders from the extraced zip -- that folder will be deleted at the end anyway
d) retry at least once if deletion of an old file/folder does not succeed

item b) could be a parameter to the updater, although I cannot imagine a scenario where one would want to delete the zip prematurely.

updater_two_modified_files.zip

[kesselb]

The updater needs to be able to work with shared hosts where limits are rather strict.

Nope. It's not the goal to support any shared web hosting out there. If rmdir returns false for whatever reason it seems more a workaround than a solution. Probably acceptable if a known quirks with rmdir.

FreeBSD 11.3-RELEASE-p6

Is not even officially supported.

[MorrisJobke]

FreeBSD 11.3-RELEASE-p6

Is not even officially supported.

Sorry to say that, but I will close the ticket. The updater itself remembers the step it is in and continues there, but if the commands return a failure, then there is not much we can do. Feel free to debug this more, but I don't see any obvious issues here.

if you have a special way to properly reproduce this then we can look into a solution, but just retry harder (which only sometimes work) and then patching out essential functionality (like the verification of the archive and the code) out is not really a solution.

[2019-05-10]

Given the frustrated comments I've seen while searching for a solution, I can't say I am surprised you're just closing this.

The updater itself remembers the step it is in and continues there, but if the commands return a failure, then there is not much we can do.

What about really remembering the last step and retrying from there? At least, that's what the updater itself suggests:

Update failed. To resume or retry just execute the updater again.

Creating a new backup, downloading the same zip again, verifying, expanding, deleting bit by bit -- again and again? That's just unnecessary waste of resources and doesn't fix anything, but most likely serves only to make sure the installer runs in the timeout each time again as well.

Allowing to skip the backup, keeping the downloaded zip, keeping the extracted zip's folder, deleting only at the very end in one go -- these are all valid points and IMO very sensible to address.

At least the CLI updater is supposedly meant to be used by people knowing (more or less) what they do -- and I got there since it was suggested to be used when the web updater runs into timeouts.
That's not true either, as it seems.

The stuff I did was to make things work. I am not familiar with NC's code nor have I coded in PHP for a long time. I attached it to illustrate my points (and help others looking for a way to make things work). Using that as an excuse just confirms my first impression.

Hopefully this ticket, closed or not, helps others, stuck in the same frustrating and poorly addressed situation.

[MorrisJobke]

Creating a new backup, downloading the same zip again, verifying, expanding, deleting bit by bit -- again and again?

That should not happen. We actually really remember the state. There is a .step file in the updater directory that should avoid all of this.

Allowing to skip the backup, keeping the downloaded zip, keeping the extracted zip's folder, deleting only at the very end in one go -- these are all valid points and IMO very sensible to address.

Skipping backup: #282

Keeping the downloaded zip works. It's the same step file I mentioned above.

At least the CLI updater is supposedly meant to be used by people knowing (more or less) what they do -- and I got there since it was suggested to be used when the web updater runs into timeouts.
That's not true either, as it seems.

CLI updater uses the exact same code and is heavily tested. It seems to be a setup issue with your system. The only difference for the CLI updater are the CLI arguments (unattended upgrade, verbose mode) and that it can not run into the timeout of the webserver as it is not executed via the webserver.

Hopefully this ticket, closed or not, helps others, stuck in the same frustrating and poorly addressed situation.

Sorry that you had such issues, but we try to make things work as good as possible. And saying that the updater itself works poorly is something I cannot confirm. It might be related that you run Nextcloud in a non-Linux environment which we don't support and don't want to spend time into as of now.

[2019-05-10]

That should not happen. We actually really remember the state. There is a .step file in the updater directory that should avoid all of this.

Well, it doesn't.
It's more than a year and two relaeses later and it still does not work.

[✘] Delete old files failed
Could not rmdir: /home/foo/nc/updater/../3rdparty/aws/aws-sdk-php/src

Update failed. To resume or retry just execute the updater again.

Manually deleting the folder and "just executing theupdater again" ... just starts from the top.
No .steps file left anywhere.

Any chance you could describe how that .steps file is supposed to look so one could create it manually?