Version: unspecified OS: Linux Originally reported against libreoffice https://bugs.freedesktop.org/show_bug.cgi?id=42362 Then found out it's KDE specific and now reporting here. Trying to open huoltopäiväkirja.ods will result to an error: "/home/user/huoltopäiväkirja.ods does not exist." renaming the file to huoltopaivakirja.ods and the file opens without problems. LibreOffice 3.3.3 OOO330m19 (Build:301) Ver: 3.3.3.1-7.fc15 Linux oc7228322058.ibm.com 2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Dolphin Version 1.6.1 Using KDE Development Platform 4.6.5 (4.6.5) Locale: LANG=en_DK.utf8 LC_CTYPE="en_DK.utf8" LC_NUMERIC="en_DK.utf8" LC_TIME="en_DK.utf8" LC_COLLATE="en_DK.utf8" LC_MONETARY="en_DK.utf8" LC_MESSAGES="en_DK.utf8" LC_PAPER="en_DK.utf8" LC_NAME="en_DK.utf8" LC_ADDRESS="en_DK.utf8" LC_TELEPHONE="en_DK.utf8" LC_MEASUREMENT="en_DK.utf8" LC_IDENTIFICATION="en_DK.utf8" LC_ALL= Reproducible: Always Steps to Reproduce: Either use dolphin (double click) on libreoffice document with high ascii in the name OR from libreoffice, select file -> open, then select filename with high ascii. Actual Results: That will result to error message: "/home/user/huoltopäiväkirja.ods does not exist." Expected Results: File opened to libreoffice renaming the file to huoltopaivakirja.ods and the file opens without problems. Using Cinnamon desktop instead of KDE, opening the file (with high ascii) also works without issues.
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.