Bug 37814 - FILESAVE Save/Save As dialogs use last save folder (not original) with non-ascii path
Summary: FILESAVE Save/Save As dialogs use last save folder (not original) with non-as...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4 Daily
Hardware: All Windows (All)
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:4.5.0 target:4.4.0.0.beta3
Keywords:
: 70463 85284 87019 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-06-01 06:26 UTC by Eugene Kin
Modified: 2014-12-12 09:59 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
path contains russian chars (93.77 KB, image/jpeg)
2011-06-01 06:26 UTC, Eugene Kin
Details
path contains only ascii chars (106.10 KB, image/jpeg)
2011-06-01 06:27 UTC, Eugene Kin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Kin 2011-06-01 06:26:31 UTC
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
Comment 1 Eugene Kin 2011-06-01 06:27:51 UTC
Created attachment 47422 [details]
path contains only ascii chars
Comment 2 LeMoyne Castle 2011-06-16 12:19:30 UTC
@Eugene: I apologize for any extra NEEDINFO emails - I am working on a greasemonkey script for LibreOffice Bugzilla
Comment 3 LeMoyne Castle 2011-06-17 19:37:03 UTC
OS->All: Reported for Linux (Ubu10.04), Mac (OS X 10.6.7) and Win (several) in 37814 and 37917
Comment 4 tester8 2011-06-19 02:07:15 UTC
>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.
Comment 5 Björn Michaelsen 2011-12-23 12:07:27 UTC
[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
Comment 6 tester8 2011-12-29 14:28:49 UTC
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.
Comment 7 tester8 2011-12-29 14:36:20 UTC
Sorry. #6 is for another bug.

Still not reproduced (but only on Linux).
@Rainer
Could you please test on Windows?
Comment 8 Eugene Kin 2012-01-16 05:22:35 UTC
Bug still exists in LibO 3.5 beta3
OS - Windows 7 SP1
Comment 9 Aaron 2012-03-27 10:49:19 UTC
Bug still exists on windows 2008 R2
Comment 10 sasha.libreoffice 2012-05-03 02:08:38 UTC
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
Comment 11 Rainer Bielefeld Retired 2012-05-03 02:40:28 UTC
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?
Comment 12 sasha.libreoffice 2012-05-03 03:01:37 UTC
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
Comment 13 sasha.libreoffice 2012-05-03 03:09:25 UTC
on Windows 7 Russian locale also reproduced with German and Chinese characters
Comment 14 Eugene Kin 2012-05-03 03:27:51 UTC
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
Comment 15 dailson.araujo 2012-05-03 13:14:48 UTC
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.
Comment 16 Eugene Kin 2012-07-03 04:40:42 UTC
Bug still exists in LibO 3.5.5 RC2 and 3.6.0.0 beta2
OS - Windows 7 SP1
Comment 17 Eugene Kin 2012-08-06 09:40:16 UTC
Bug still exists in LibO 3.6.0 RC4
OS - Windows 7 SP1
Comment 18 Eugene Kin 2013-03-14 08:18:34 UTC
Bug is still there
LibO - 4.0.2.1
OS - Windows 7 SP1
Comment 19 Eugene Kin 2013-06-06 06:45:43 UTC
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)
Comment 20 Michael Stahl (CIB) 2013-06-06 09:33:59 UTC
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.
Comment 21 Don't use this account, use tml@iki.fi 2013-06-06 09:53:39 UTC
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.
Comment 22 Eugene Kin 2013-06-06 13:21:52 UTC
Saying ASCII I mean US-ASCII, so this issue extends to paths containing umlauts and other diacritic that widely used in many languages
Comment 23 Don't use this account, use tml@iki.fi 2013-06-06 13:45:12 UTC
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;)
Comment 24 Rubem 2013-10-17 13:48:59 UTC
> 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).
Comment 25 Urmas 2013-10-17 22:52:36 UTC
*** Bug 70463 has been marked as a duplicate of this bug. ***
Comment 26 arcfi 2014-08-04 08:49:22 UTC
Affects LibreOffice 4.2.5 on Windows 7 Professional.
Comment 27 Urmas 2014-10-21 12:00:25 UTC
*** Bug 85284 has been marked as a duplicate of this bug. ***
Comment 28 Urmas 2014-12-12 02:02:07 UTC
*** Bug 87019 has been marked as a duplicate of this bug. ***
Comment 29 Stephan Bergmann 2014-12-12 09:19:17 UTC
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).
Comment 30 Commit Notification 2014-12-12 09:53:17 UTC
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.
Comment 31 Commit Notification 2014-12-12 09:56:49 UTC
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.