Invalid cache directory when user name contains an umlaut

[gpoehl]

After self-update to version 2.2.3 composer ignores existing umlaut in a user name.

EG: User name is Günter

Before the self update the directory
C:/Users/Günter/AppData/Local/Composer/files/
was used.
Now it is
C:/Users/Gnter/AppData/Local/Composer/files/

So it is not even posssible to rollback to the previous version.

[Seldaek]

You can do a fresh install with instructions from https://getcomposer.org/download/

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '906a84df04cea2aa72f40b5f787e49f22d4c2f19492ac310e8cba5b96ac8b64115ac402c8cd292b8a03482574915d1a8') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php --version=2.1.14
php -r "unlink('composer-setup.php');"

Please check if 2.1.14 works, and ideally if you can check versions in between (2.2.0, 2.2.1, ..) to identify which one exactly broke this that would be great.

Can you also check what echo $Env:LOCALAPPDATA outputs in powershell, or try to get the value of that env var within whatever terminal you're using for Composer?

It'd be good to get more details, what env you are in, what error you see, etc.

[gpoehl]

I run the tests as mentioned.

Version 2.1.14 works fine.
echo $Env:LOCALAPPDATA outputs C:\Users\Günter\AppData\Local

The error comes with version 2.2.0. Message:
Cannot create cache directory C:/Users/Gnter/AppData/Local/Composer/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache

echo $Env:LOCALAPPDATA still outputs C:\Users\Günter\AppData\Local

My current php version is 8.0.7

[Seldaek]

OK could you check/share what php -r "var_dump($_SERVER['LOCALAPPDATA'] ?? 'unset', $_ENV['LOCALAPPDATA'] ?? 'unset', getenv('LOCALAPPDATA'));" outputs?

It's the only clue I have as to what would have caused a change here in 2.2 right now

[gpoehl]

The output is fine.

array(1) {
[0]=>
string(12) "LOCALAPPDATA"
}
array(1) {
[0]=>
string(12) "LOCALAPPDATA"
}
string(30) "C:\Users\Günter\AppData\Local"

[Seldaek]

Uhh those first two make no sense to me.. can you put this in a test.php file and run it from CLI?

<?php
var_dump($_SERVER['LOCALAPPDATA'] ?? 'unset', $_ENV['LOCALAPPDATA'] ?? 'unset', getenv('LOCALAPPDATA'));

php test.php

[gpoehl]

Now I'm surprised.

C:\Daten\WebRoot\test>php test.php
string(29) "C:\Users\Gnter\AppData\Local"
string(5) "unset"
string(30) "C:\Users\Günter\AppData\Local"

[Seldaek]

Ahh. OK so $_SERVER has the wrong info in it somehow, that makes sense as we started reading from $_SERVER as well as getenv in 2.2.. I wonder if that's a PHP bug then.

[Seldaek]

Can you try/check if you have default_charset = "utf-8" in php.ini?

[gpoehl]

It's in uppercase.
default_charset = "UTF-8"

[Seldaek]

In powershell I get this:

PS C:\Users\seld> $env:FOO = 'C:\Users\Günter'
PS C:\Users\seld> php .\test.php
string(15) "C:\Users\G�nter"
string(5) "unset"
string(16) "C:\Users\Günter"

cmd.exe too:

C:\Users\seld>set FOO=Günter

C:\Users\seld>php test.php
string(6) "G�nter"
string(5) "unset"
string(7) "Günter"

in bash/WSL it works fine though:

$ export FOO=Günter
$ php ~/test.php
/mnt/c/Users/seld/test.php:3:
string(7) "Günter"
/mnt/c/Users/seld/test.php:3:
string(5) "unset"
/mnt/c/Users/seld/test.php:3:
string(7) "Günter"

So it does appear to be a PHP-on-Windows bug. I filed a report on php/php-src#7896 - let's see if someone else has more of a clue. Otherwise I'll have to try and make a workaround in Composer.

[Seldaek]

@gpoehl please try again after a composer self-update --snapshot, hopefully it properly resolves it for you. Seems to work here but I only have an artificial test env..

[gpoehl]

@Seldaek ,
trying to install the snapshot fails. Error message:

[ErrorException]
file_put_contents(C:/Users/Gnter/AppData/Roaming/Composer/update-channel): Failed to open stream: No such file or
directory

Can I delete the globally installed version, then install version 2.1.14 and after this run the self-update --snapshot?

[Seldaek]

Yes sure that'll work

[gpoehl]

Sorry that I've come back with another question.
How can I install an old version? Installer installs version 2.2.3.
I managed to download a composer.phar file for version 2.1.14 but don't know how to install it.

[Seldaek]

See #10434 (comment) there's a --version flag for the composer-setup.php script. If you use the exe installer there's no way to do that I believe, you'd have to manually place the new phar file on top of wherever the exe installer installed the other phar.

[gpoehl]

I installed composer using the exe installer and replaced the composer.phar file within the 'programData\ComposerSetup\bin' directory. So I had a clean 2.1.14 version.
On this version running composer self-update --snapshot went well.

The snapshot itself solved the problem.
Thanks a lot.

[gpoehl]

@Seldaek ,
the problem hasn't been solved completely. Rollback still uses the wrong directory name.

C:>composer -V
Composer version 2.3-dev (2.3-dev+f1568f1f8f95686aa101452818d88f18225bc194) 2022-01-07 08:30:43

C:>composer self-update --rollback

In SelfUpdateCommand.php line 405:

Composer rollback failed: no installation to roll back to in "C:/Users/Gnter/AppData/Roaming/Composer"

self-update [-r|--rollback] [--clean-backups] [--no-progress] [--update-keys] [--stable] [--preview] [--snapshot] [--1] [--2] [--set-channel-only] [--] []

C:>composer -V
Composer version 2.3-dev (2.3-dev+f1568f1f8f95686aa101452818d88f18225bc194) 2022-01-07 08:30:43

[Seldaek]

OK that I cannot make any sense of :s

[johnstevenson]

getenv() without the param returns the scrambled value, whereas getenv('name') doesn't.

[Seldaek]

Oh god.. I still had some other version of the workaround in my test file so I did not notice that 🤯

But then the snapshot did not fix anything at all.. Anyway fixing again, better

[Seldaek]

Alright @gpoehl please try again with d961998 and please verify that the snapshot really works because I think the previous one did not resolve anything at all, I'm not sure what made you believe it worked until you try the rollback.

[gpoehl]

I can confirm that version 2.2.4 solved the problem.

My previous assumtion, that your first fix alredy solved the problem, might have been wrong. It looks like that I run the tests in a powershell with administrator rights. The snapshot version created a new user in the user directory and run without providing an error message.
Again, thanks a lot.