Created attachment 47421 [details] path contains russian chars If the path to file contains non-ascii chars save/save as dialog opens in the last save folder instead of original one. D:\Документы -> Рабочий стол (Desktop in Russian) = FAIL If path contains only ascii chars save/save as dialog opens in original folder of the file. D:\Temp -> D:\Temp = OK OS - Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2 LibO version - all
Created attachment 47422 [details] path contains only ascii chars
@Eugene: I apologize for any extra NEEDINFO emails - I am working on a greasemonkey script for LibreOffice Bugzilla
OS->All: Reported for Linux (Ubu10.04), Mac (OS X 10.6.7) and Win (several) in 37814 and 37917
>Reported for Linux (Ubu10.04), Mac (OS X 10.6.7) and Win (several) in 37814 and 37917 This bug NOT reproduced with Ubuntu 10.04.2 x86 LO 3.4 (desktop integration installed). So it is not duplicating bugs, but part of one problem.
[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 NOT reproduced. Long closing but no crash.
Sorry. #6 is for another bug. Still not reproduced (but only on Linux). @Rainer Could you please test on Windows?
Bug still exists in LibO 3.5 beta3 OS - Windows 7 SP1
Bug still exists on windows 2008 R2
reproduced in 3.5.2 on Windows 7 32 bit File should placed on Samba share drive. For example, if path is this: \\server\docs\Разное\1 Then using File->Save as, file will be saved in another place, for example to D:\1
NOT reproducible with a file named Български1.odt in a folder with same name (and additional subolders with ascii names) and "LibreOffice 3.5.3.2 (RC2) German UI/Locale [Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80] on German WIN7 Home Premium (64bit), but I am not sure whether I understood all details of the report. I saved on a normal PC drive, A WIN defined Network drive and on same network drive via network access (only possible with OS filesave dialog). For me everything worked fine. May be only visible with Samba drives or similar? Modified Version due to rare available info. @all. did anyone ever see that working with LibO or OOo?
Additional tests: on Windows XP not reproducible on Windows 7 Russian locale reproducible, even with local drive (Desktop for example). IMHO or Russian specific or locale specific (more probably), it means problem is only with language, corresponding to Windows locale
on Windows 7 Russian locale also reproduced with German and Chinese characters
OK. I'll try to make it clear now. There is folder D:\Test and 2 subfolders in it: ASCII and Кириллица And there is file Test.odt in each subfolder. Step 1. Open file D:\Test\ASCII\Test.odt and open SAVE AS dialog. It opens in D:\Test\ASCII folder as expected. Select D:\Test folder in SAVE AS dialog and save file as Test1.odt. Result - test OK. Step 2. Open file D:\Test\Кириллица\Test.odt and open SAVE AS dialog. It opens in D:\Test folder, but it should be open in D:\Test\Кириллица. Select D:\Test folder in SAVE AS dialog and save file as Test2.odt. Result - test failed (wrong folder) Step 3. Open file D:\Test\ASCII\Test.odt and open SAVE AS dialog. It opens in D:\Test\ASCII folder as expected. Result - test OK (again). OS - Windows 7 Russian, Windows Server 2008/2008 R2 as well LibO version - 3.5.3.2
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 FILEOPEN FILESAVE don't accept non-ascii paths https://bugs.freedesktop.org/show_bug.cgi?id=37917 ------------------------------------------------------ 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.
Bug still exists in LibO 3.5.5 RC2 and 3.6.0.0 beta2 OS - Windows 7 SP1
Bug still exists in LibO 3.6.0 RC4 OS - Windows 7 SP1
Bug is still there LibO - 4.0.2.1 OS - Windows 7 SP1
I guess this all about the same issue https://bugs.freedesktop.org/show_bug.cgi?id=51473 https://bugs.freedesktop.org/show_bug.cgi?id=51149 http://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=41477 This functionality works in different ways on Windows XP (correct one) and on Windows Vista and above (incorrect). Lotus Symphony's native SAVEAS Dialog opens in proper folder on all Windows (XP, Vista, Seven, 2008)
Tor, does this have anything to do with bnc#777788 (could be duplicate)? can somebody test if this is fixed in LO 4.1 beta1 or master? note: there are 2 different "native" Win32 file pickers, one is used on Vista and later, the other used on older Windows.
But in bnc#777788 and fdo#63622 whether pathnames were ASCII-only or not had no relevance. The initial comment here claims that what this bug is about happens only for non-ASCII file directory names.
Saying ASCII I mean US-ASCII, so this issue extends to paths containing umlauts and other diacritic that widely used in many languages
I do know what ASCII is, and yes, US-ASCII is a synonym. And yes, I and other developers are fully aware what non-ASCII characters are. Most of us use such in our native languages;)
> can somebody test if this is fixed in LO 4.1 beta1 or master? Yes, the bug is still there. My LO version is 4.1.2.3 (Windows 7, Brazilian Portuguese).
*** Bug 70463 has been marked as a duplicate of this bug. ***
Affects LibreOffice 4.2.5 on Windows 7 Professional.
*** Bug 85284 has been marked as a duplicate of this bug. ***
*** Bug 87019 has been marked as a duplicate of this bug. ***
The problem is that fpicker/source/win32/filepicker/VistaFilePickerImpl.cxx:687 HRESULT hResult = SHCreateItemFromParsingName ( sDirectory.getStr(), NULL, IID_PPV_ARGS(&pFolder) ); with sDirectory being "file:///C:/Folder%20one/Pe%C3$A7as/Folder%20two/" fails with hResult being HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND).
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e123ffd66088783ce74a7b5f15e9d324b39ecf67 fdo#37814: SHCreateItemFromParsingName doesn't like LO's file URLs It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=483e7103e895f4da84aa7de94938b373b5fcd64b&h=libreoffice-4-4 fdo#37814: SHCreateItemFromParsingName doesn't like LO's file URLs It will be available in 4.4.0.0.beta3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.