Grav fails to update through GUI admin or CLI if you are using =>php 8 and any Built in Server (development)

[spamhater-grav]

Whilst updating the last couple of version of Grav through admin, the update will fail if you are running the symphony / grav built in server ( bin/grav -server )

workaround, is to run php's server command before doing the update ( php -S localhost system/router.php ) to carry out the process through the gui or manually update the install via a zip file to replace the bin\grav folder

I am not sure at how it stands for the other files which have been updated and if the priority of the update and the removal / addition of files / point of error occurring is at the top of the priority list or at the end (after update is completed)

But if the update fails, due to the file being present in the bin\ directory where the other file have been removed, the install fails because the bin\grav is in use . This will then produce an sfetch error.

Grav 1.7.28 and 1.7.29 & PHP 8.1.0

Tested . Downloaded 1.7.28 Expanding to directory R:\grav-test Started server at command line PHP bin\grav server Created admin user and login in to panel Notification of update available (17.29) Clicked update now States that it is downloading update

Error appears straight away (Sfetch rmdir r:/grav-test/bin - Directory not empty)

The only line the web server reports is

[Web Server ] Jan 30 22:46:12 |INFO | SERVER GET (200) /admin/update.json/task:updategrav/admin-nonce:35bb47ddb29edd41693973ce70bad1ed

[spamhater-grav]

07/02/22 Small update. This issue is related to, when you are doing the update when grav and php 8.x is used.

Thought I would just eliminate a thought, so tested a fresh setup 7.1.26

under php 7.4 UPDATE COMPLETES FINE NO ERRORS \phpgrav7 under php 8.x UPDATE FAILS \phpgrav8 (above error is thrown)

This might just help to target the problem and not send you off an wild goose chase. This also applies to the php or grav built in server called in php 8.1

[OleVik]

Is this OS-specific? Is there a complete error-stack that you could include?

[mahagr]

Looks like either a Windows issue or a permissions issue.

In Windows, you cannot delete open files (which is fine in almost any other OS/filesystem), but on the other hand, Grav shouldn't use anything from /bin when in the admin.

Another possibility is bad permissions in that folder.

[spamhater-grav]

I found the issue occurred after an update to php8 update and the following grav updates, it looks like it downloaded correctly.

Its fully understandable about permission and open files , but this was on a fully accessible folder and then I then rolled back / switched back to php 7.4 and the error didn't occur in the exact same folder.

I presume it may be the way php (or as a composer) has handle or changed the install method Happy to test other configurations or replicate the error with any guidance of possible fixes :)

Composer installed locally - currently 2.2.9 and now running

PHP 8.1.3 (cli) (built: Feb 16 2022 08:20:53) (NTS Visual C++ 2019 x64) Copyright (c) The PHP Group Zend Engine v4.1.3, Copyright (c) Zend Technologies with Zend OPcache v8.1.3, Copyright (c), by Zend Technologies with Xdebug v3.1.1, Copyright (c) 2002-2021, by Derick Rethans

Could it be a windows temp / php opcache folder issue ? Will test with an vanilla php and go through it again and report back

[mahagr]

I don't think it's an issue in PHP8, I think that killing PHP freed the file or it would have been working fine the second time anyway.

I have seen people reporting issues like this before, where the folder fails to delete. All were in Windows. Like I said, in Windows you cannot delete files that are open. Do you have cron jobs enabled? Did you use CLI?

That said, there seems to be a real issue here as it should stop at the error on the locked file, not later when it attempts to delete the folder.

[OleVik]

@spamhater-grav Please let us know your Windows-version, contents of php.ini, and relevant error-stack from /logs/grav.log. This is, as Matias points out, a typical error in Windows when the process that runs PHP isn't one step removed from ownership of the files. It's therefore quite rare with intermediary systems like Apache, NGinx, Caddy, etc.

[spamhater-grav]

Hi @OleVik and @mahagr , was just writing my reply as you posted

No there was no cron jobs running, tested with fresh install out of the box / out of the zip Currently only testing with a local php test server (using either php -s localhost:8888 or php bin/grav server), (no apache /nginx)

I have been able to reproduce the error without being in a browser admin and purely from command line.

Steps taken

1. Created a local directory , open archive grav 1.7.28 (closest to hand) , extracted files to directory
2. Ran the php server command line (as per symfony / php cli server)
3. Open grav through the browser and logged in to site (setting up admin and showing notification of update - hence working)
4. Came out of browser
5. Terminated the running php server command line
6. Changed to the local install directory
7. ran the command php bin/gpm -selfupgrade -vvv (entered yes on prompts)

Output Dependencies updating

Preparing to upgrade to v1.7.32.. |- Downloading upgrade [8.73M]... 100% |- Installing upgrade... error | '- Unknown error '- Installation failed or aborted.

The \bin folder is left completely empty. I found no log file since I can replicate from a fresh install and no site user interaction, but straight away running update from the command line.

I wait further discussion, will do a fresh php install no debug / opcache etc :)

php.txt php.ini (renamed) included

[mahagr]

I tested this in Ubuntu / PHP 8.1 and everything works. Note that if you change install directory, you may want to clear cache, though in my case it still worked.

Unfortunately I do not have any Windows PCs, which means I cannot test this on Windows.

[jwillp]

Encountered the same issue on a production linux system, while trying to update plugins. A workaround was to use the gpm binary.