I already discussed this bug on OOo lists a long time ago but nobody seems to be able to reproduce it. Basically, when I try to open a file which path is composed of non ascii characters (I often use Japanese), OOo as well as LO (but not NeoOffice) tell me that the file does not exist. When I try to save to a path that includes non ascii characters, OOo/LO rewrite the path (file name, folders) so that it does not include non-ascii characters. I have not been able to identify the cause of the bug. I logged in guest accounts on my machine and the bug was not present. But even after removing all the preferences from my ~/Library/, it was still there.
Reproduced with Ubuntu 10.04.2 LO 3.4 To reproduce: Run in terminal: export LANG=C libreoffice3.4 Then try to grad and drop file with NON-ASCII symbol in name. For example "И" (copy it from this message). LO will say that file does not exists. It is possible to open throught File->Open, but name of file in the window title is damaged. Save also works, but produce messages in the console (soffice:4826): Gtk-WARNING **: Unable to retrieve the file info for `file:///home/tester8/%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B8%D0%B9%2520%D1%81%D1%82%D0%BE%D0%BB/%D0%98.odt': Error stating file '/home/tester8/???????%20????/?.odt': No such file or directory ???????%20???? means "Рабочий стол" - russian localisation for Desktop. If I launch LO without pre-export language, it is all right for files with ASCII, cyrillic and jappanese characters in name at the same time
On the Mac I'm wondering if this is related to FileVault? With two different user accounts, one with FileVault enabled, one without: 1. create a folder with a special character on the Desktop, in this case Māori (that's a macron above the 'a') 2. open LO and from the start page select a new text document 3. type some gibberish 4. save the file into the new folder on the Desktop 5. on the FileVault protected a/c the folder name will decompose (I'm guessing) into Ma?ori. Under the non-FileVault a/c the file is saved correctly. This happens irrespective of the 'save' folder being located within the FileVault or not. The LO application is in the main Applications folder (so not within a FileVault). This also happened under OpenOffice but not NeoOffice. OS X 10.6.7
OS->All: Reported for Linux (Ubu10.04), Mac (OS X 10.6.7) and Win (several) in 37814 and 37917
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
LOdev 3.5.0beta2 4ca392c-760cc4d-f39cf3d-1b2857e-60db978 Ubuntu 10.04.3 x86 Linux 2.6.32-37-generic Russian UI Same behavior.
Due to Comment 5
Reproduced in: Product: LibreOffice Component: UI Version: 3.4.5, 3.4.6 e 3.5.3. Plataform: Windows 7 64-bit Download: www.libreoffice.org Language: Portuguese (Brazilian) Not Reploducible on Windows XP 32-bit Meaningful Summary: LibreOffice does not maintain the correct path of the file when using "Save As ..." in a way that at an intermediate level have folder with non-ascii characters (ç, ã, is ô, etc.). Example "C:\Folder One\Peças\Folder Two" Steps to reproduce the problem: 1) Create the following directory structure: "C:\Folder One\Peças\Folder Two" 2) Note that we have the character "ç" in a folder intermediate 3) Copy a file (document or spreadsheet) into the "Folder two" 4) Open the file copied to the "Folder Two" and select "File > Save as ..." 5) Note that the LibreOffice does not correctly recognize the target directory, which is generally the same source file. In this case, the destination directory should be "C:\Folder One\Peças\Folder Two" but when we have non-ascii characters are used the last folder where a file was saved. Option 1 workaround: 1) When the dialog box "Save as ..." is displayed, you can manually select the target location, eg "C:\Folder One\Peças\Folder Two" 2) After manually select the target location LibreOffice recognize the correct place for the next time you "Save as ..." is triggered. Option 2 workaround: 1) If the dialog box is used LibreOffice (Tools > Options ...> LibreOffice > General > Dialog Open and Save > Use LibreOffice dialogs), this error does not occur. Related Bugs: LibreOffice is unable to manage paths with accentuated characters https://bugs.freedesktop.org/show_bug.cgi?id=45063 FILESAVE Save/Save As dialogs use last save folder (not original) with non-ascii path https://bugs.freedesktop.org/show_bug.cgi?id=37814 ------------------------------------------------------ Original text in Portugês Produto: LibreOffice Componente: UI Sistema Operacional: Windows 7 64-bit Versão do LibreOffice Testadas: 3.4.5, 3.4.6 e 3.5.3. Download: www.libreoffice.org Idioma: Português (Brasil) Problema não Ocorre em Windows XP 32-bit Resumo do problema: O LibreOffice não mantém corretamente o caminho de destino do arquivo quando se utiliza o opção "Salvar Como..." em um caminho em que em um nível intermediário temos diretórios com caracteres latinos (ç, ã, é ô, etc). Exemplo "C:\Pasta um\Peças\Pasta dois" Passos para reproduzir o erro: 1) Crie a seguinte estrutura de diretórios: "C:\Pasta um\Peças\Pasta dois" 2) Observe que temos o caracter "ç" em uma pasta intermediária 3) Copie um arquivo (documento ou planilha) para dentro da "Pasta dois" 4) Abra o arquivo copiado para a "Pasta dois" e selecione "Arquivo > Salvar como..." 5) Observe que o LibreOffice não reconhece corretamente o diretório de destino, que em regra é o mesmo do arquivo de origem. No caso, o diretório de destino deveria ser "C:\Pasta um\Peças\Pasta dois", mas quando temos caracteres não-ascii é utilizada a última pasta onde um arquivo foi salvo. Opção 1 para contornar o problema: 1) Quando a caixa de diálogo "Salvar como ..." for mostrada, é possível selecionar manualmente o local de destino, por exemplo "C:\Pasta um\Peças\Pasta dois". 2) Após selecionar manualmente o local de destino o LibreOffice reconhecerá corretamente o local de destino nas próximas vezes que a opção "Salvar como ..." for acionada. Opção 2 para contornar o problema: 1) Caso a caixa de Diálogo do LibreOffice seja utilizada (Ferramentas > Opções ... > LibreOffice > Geral > Caixa de diálogo de Abrir e Salvar > Utilizar as caixas de diálogo do LibreOffice), o referido erro não ocorre.
Can't reproduce with last master branch using Ubuntu 12.10. Can you test in Ubuntu? If this works, I believe we can change the OS target in this bug :)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1.2 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
(In reply to dailson.araujo from comment #7) > Reproduced in: > > Product: LibreOffice > Component: UI > Version: 3.4.5, 3.4.6 e 3.5.3. > Plataform: Windows 7 64-bit > Download: www.libreoffice.org > Language: Portuguese (Brazilian) > > Steps to reproduce the problem: > > 1) Create the following directory structure: "C:\Folder One\Peças\Folder Two" > 2) Note that we have the character "ç" in a folder intermediate > 3) Copy a file (document or spreadsheet) into the "Folder two" > 4) Open the file copied to the "Folder Two" and select "File > Save as ..." > 5) Note that the LibreOffice does not correctly recognize the target > directory, which is generally the same source file. In this case, the > destination directory should be "C:\Folder One\Peças\Folder Two" but when we > have non-ascii characters are used the last folder where a file was saved. Not reproduced on Win 7 and Ubuntu was reported as working, so closing as WFM. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI