Unable to open files with accented characters in the filename: The operation on /file/path was started with an invalid parameter

[juliohm1978]

Libreoffice inside flatpak is unable to open filenames with international accented characters, such as ã,ç,é,ó.

For example: Quadro implantação_v2.xlsx

Renaming the file to remove the accents is a workaround.

[stbergmann]

(1) When you run the flatpak from a shell via flatpak run org.libreoffice.LibreOffice, does it exhibit the failure you desribe? If yes, then what is the output of running flatpak --command=locale run org.libreoffice.LibreOffice in that same shell?

(2) What is the exact sequence of byte values that make up the filename that you see as "Quadro implantação_v2.xlsx"? What should help to determine that is to run LC_ALL=POSIX ls 'Quadro implantação_v2.xlsx' in a shell (and cd ... to the right directory) and provide its output.

[juliohm1978]

Thank you, @stbergmann ! You just gave me the insight to find out what's going on.

Like most people, I'm used to double clicking the file from the file explorer to open it. In fact, using the application menu (File>Open) from inside the running application works.

Looks like a clear case for incompatible locales when the system file explorer tries to launch LibreOffice as a response to the user double clicking the file.

I'm using Gnome 43, and my locale is configured for Brazilian Portuguese:

$> env | egrep '^LC_'
LC_PAPER=pt_BR.UTF-8
LC_CTYPE=pt_BR.UTF-8
LC_TIME=pt_BR.UTF-8
LC_ADDRESS=pt_BR.UTF-8
LC_TELEPHONE=pt_BR.UTF-8
LC_IDENTIFICATION=pt_BR.UTF-8
LC_MONETARY=pt_BR.UTF-8
LC_ALL=en_US.UTF-8
LC_NUMERIC=pt_BR.UTF-8
LC_NAME=pt_BR.UTF-8
LC_MEASUREMENT=pt_BR.UTF-8

Special note to the fact that, while all other variables keep the Brazilian format for numbers, the preferred language I use is still LC_ALL=en_US.UTF-8.

This is what the flatpak locale looks like:

$> flatpak --command=locale run org.libreoffice.LibreOffice
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

I'm not quite sure where the mismatch comes from, since LC_ALL is apparently the same inside the flatpak.

In any case, to work around this, there are two options:

1) Change my system locale globally to en_US

2) Include LC_ALL=en_US.UTF-8 as global environment variable for all flatpaks (eg: using FlatSeal).

[chrisawi]

Special note to the fact that, while all other variables keep the Brazilian format for numbers, the preferred language I use is still LC_ALL=en_US.UTF-8.

LC_ALL is an override for all the other locale variables, so flatpak isn't doing anything different here. If you try locale in a host shell, you should see the same thing. I think you intended to set LANG, but if you're using GNOME, I would suggest using the Region & Language panel rather than setting locale variables manually.

I can reproduce the error here using LC_ALL=pt_BR.UTF-8 flatpak run org.libreoffice.LibreOffice on an en_US system. Flatpak hasn't installed the Locale extension subsets for pt, so LibreOffice falls back to the C locale and can't handle the UTF-8 filename.

For installing locale subsets in the system installation, flatpak gets the locale from localed and AccountsService. If you have your system locale set to pt_BR.UTF-8 (as shown in flatpak config), and you've overridden it in your session via LC_ALL=en_US.UTF-8, you may be in an equivalent situation.

Does flatpak run --command=locale org.libreoffice.LibreOffice -a list en_US.utf8 as a supported locale?

[juliohm1978]

Does flatpak run --command=locale org.libreoffice.LibreOffice -a list en_US.utf8 as a supported locale?

Yes, it does.

$> flatpak run --command=locale org.libreoffice.LibreOffice -a
C
C.utf8
en_AG
en_AU
en_AU.utf8
en_BW
en_BW.utf8
en_CA
en_CA.utf8
en_DK
en_DK.utf8
en_GB
en_GB.utf8
en_HK
en_HK.utf8
en_IE
en_IE@euro
en_IE.utf8
en_IL
en_IN
en_NG
en_NZ
en_NZ.utf8
en_PH
en_PH.utf8
en_SG
en_SG.utf8
en_US
en_US.utf8
en_ZA
en_ZA.utf8
en_ZM
en_ZW
en_ZW.utf8
POSIX

Adjusting the locale has corrected the issue for me. Thank you!