yes we have hard filtering of file names for security reason.

I understand file names get filtered, but this does not seem related. Why does setting the correct locale circumvent the filtering?
I feel like filtering should be done after correctly interpreting the code points with the correct locale.

But I may be wrong.

If only ASCII (or even a more reduced subset) is allowed, a note should advise users to rename their files (and only list allowed characters). Though this seems pretty uncommon. There should be standard functions to sanitize the string and frankly, umlauts don't seem all too dangerous :)

«yes we have hard filtering of file names for security reason. » ???

Filtering äöü have nothing with security , andis not filtered like this in 'Upload question' type.

@tbart : where it's filtered like this ? And what is the broken locale

Your filenames do not start with special characters. See screenshot attached.

The locale should be en_US.UTF-8, at least that's what the environment sets for LANG:

set | egrep "^(LANG|LC)"

LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_NUMERIC=de_AT.utf8
LC_PAPER=de_AT.UTF-8
LC_TIME=de_AT.utf8

umlauts_at_the_beginning_cut_off.png (25,639 bytes)   

umlauts_at_the_beginning_cut_off.png (25,639 bytes)   

My filename was äöü.png ;) , but my locale is OK.

Can show your current locale in PHP ?

Sorry, I misread your screenshot and thought the left column were the filenames, my bad.

phpinfo() gives me:
LANGUAGE en_US:en
LANG C

It's still strange why only umlauts at the beginning get stripped off. This should not be locale dependent!

Please update to the latest version and check if the bug can still be reproduced. Thank you.

I can confirm this is still broken in Version 3.25.17+210309.
Attached is a sample survey+file. Uploading the file results in a file name "sterreich.png"

Adding

setlocale(LC_ALL, 'en_US.UTF8');

in index.php still fixes it.

österreich.png (861 bytes)   

österreich.png (861 bytes)   

@ollehar did this need a fix here ?
Server issue or not ?

Else : simple fix :

if(empty(setlocale(LC_ALL,0)) {
    setlocale(LC_ALL, 'en_US.UTF8');
}

I don't have way to reproduce : need to broke my PHP ;)

@tbart : can you check with ONLY setlocale(LC_CTYPE, 'en_US.UTF8'); ?

Way to reproduce : config.php : setlocale(LC_CTYPE,"C");

Must check if i can fix without setlocale (f**king crosoft and unsure en.utf8 exist).

LC_TYPE to C

$filename = österreich.png
basename($filename) = sterreich.png

basename() is locale aware, so for it to see the correct basename with multibyte character paths, the matching locale must be set using the setlocale() function. If path contains characters which are invalid for the current locale, the behavior of basename() is undefined.

https://www.php.net/manual/en/function.basename.php

This is on a Debian and/or Ubuntu server.
I just found out that as a default, they set LANG to C in /etc/apache2/envvars.

So

if(empty(setlocale(LC_ALL,0)))
[..]

(with 3 closing brackets :-) ) is not true, so this does not help.

setlocale(LC_CTYPE, 'en_US.UTF8');

alone does help as well.

On a not so unrelated sidenote:
This only works as long as Apache does not have mod_perl2 enabled as well, starting on Ubuntu 20.04 at least. See https://bugs.php.net/bug.php?id=81596 for details.
It seems to be generally discouraged to setlocale() in an application, so I am unsure as to whether my suggested "fix" for this issue is good or not. Maybe I did not understand nikic correctly in that thread and it is only discouraged for strftime()?

However, as Debian/Ubuntu(/most likely all other Debian based distros) - which will make up a huge percentage of all limesurvey installations I guess - set "C" as their default domain, some fix needs to be devised.
Maybe a documentation hint is necessary (mentioning the mod_perl2 issue would be practical as well, it took be hours to find this)?
Setting the locale via /etc/apache2/envvars is not thoroughly tested by me, I cannot state whether this is an actual fix that works without any side effects.

How is your/everyone else's server setup so it seems it does not use "C" as a default locale?

What I still don't get is why utf-8 characters in the middle of a filename work with the "C" locale and those at the beginning don't. This really seems like a limesurvey bug, still.

Oups, link with pull request not done
3.x https://github.com/LimeSurvey/LimeSurvey/pull/2134
master https://github.com/LimeSurvey/LimeSurvey/pull/2133

Discussion ongoing in github

Add related : 17718: sanitize_filename didn't really fix filename for all system
https://bugs.limesurvey.org/view.php?id=17718

My patch for 17718 only fixes it for version 5.

Fixed in 5.
Specific issue in 3.X
OK to closes this one ?