Bug 295212

Just curious, what program was used to create the file? If the system's locale is UTF-8 (which today it usually is), then applications should encode file names in that encoding. I am sure the file name is encoded in a different encoding. Try "convmv" to fix the encoding of the file name.

This could be a duplicate of bug 165044...

The issue is repeatable by renaming an openoffice/libreoffice file to have a name containing high ascii. 
Also, checked with convmv, the filenames I've tested already have been UTF8 encoded.

Interesting point being, if I create .txt file (touch tässä-testi.txt) and double click on dolphin, no issues.
It has something to do with libreoffice, yet it's only re-produceable when logged on KDE desktop.

Btw. I've yet to see anyone confirm them renaming a file and experiencing the same as I report. Everyone just offers the convmv solution.
So just for the record, I'd appreciate anyone testing with UTF8 locale:
1) create spreadsheet, save as test.ods
2) from shell: mv test.ods tässä_test.ods
3) try opening via libreoffice (or double click)
record the result here.

Someone commented if this was a duplicate of #165044
Testing the case from comment 34
https://bugs.kde.org/show_bug.cgi?id=165044#c34

I could not duplicate that behaviour. I was able to create 
étang planté sur le château.txt
and open it both with kwrite (file-open)
and by dolphin (double click)

(In reply to comment #3)
> 1) create spreadsheet, save as test.ods
> 2) from shell: mv test.ods tässä_test.ods
> 3) try opening via libreoffice (or double click)

After following these steps, I can open that file by clicking it in Dolphin without problems.

As Frank was not able to re-produce the issue, I got an idea.
I changed my locale setting in /etc/sysconfig/i18n to: de_DE.utf8  
restarted (just in case) and tested.

The issue does not happen with de_DE.utf8

Anyone care to try setting their system to en_DK.utf8 and verify the issue?

(In reply to comment #6)
> Anyone care to try setting their system to en_DK.utf8 and verify the issue?

I can reproduce the problem after switching locale to en_DK.UTF-8 when using KDE SC 4.9 RC2 and libreoffice 3.5.4 .

Resetting assignee to default as per bug #305719

I suspect this is a problem of the kde integration module of libreoffice, because under the en_DK.UTF-8 locale: 

    caligra suite can open that file 
    libreffoce(without kde integration module) can open that file
    libreffoce(with kde integration module) can't open that file

So maybe the reporter should reopen the report on freedesktop

I have a similar problem with locale mn_MN.UTF8, except I don't know any workaround.
I reported it there:
https://bugs.mageia.org/show_bug.cgi?id=7797
Files whose paths contains non ASCII-characters won't open with LibreOffice in Mageia, whatever be the method (line command, Dolphin, or from LibreOffice: File → Open...).

$ locale
LANG=mn_MN.UTF-8
LC_CTYPE=mn_MN.UTF-8
LC_NUMERIC=mn_MN.UTF-8
LC_TIME=mn_MN.UTF-8
LC_COLLATE=mn_MN.UTF-8
LC_MONETARY=mn_MN.UTF-8
LC_MESSAGES=mn_MN.UTF-8
LC_PAPER=mn_MN.UTF-8
LC_NAME=mn_MN.UTF-8
LC_ADDRESS=mn_MN.UTF-8
LC_TELEPHONE=mn_MN.UTF-8
LC_MEASUREMENT=mn_MN.UTF-8
LC_IDENTIFICATION=mn_MN.UTF-8
LC_ALL=

By the way, what does "RESOLVED DOWNSTREAM " mean? I can't find this in the list of valid status when clicking on "Status" here above. Such a naming is confusing, because it seems the bug is resolved, while it has just been transfered upstream.

A bug is RESOLVED in this bug tracker, if no further work needs to be done by KDE developers. The resolution DOWNSTREAM indicates that the issue is caused by software provided by the distributions.

In this case, the bug is with the LibreOffice KDE integration module (see comment #9). Please ask in a forum of your distribution, where to report bugs for that module.