Apache OpenOffice (AOO) Bugzilla – Issue 127589
Wrong path suggested at "save as" when original path contains non-ASCII characters
Last modified: 2019-10-09 14:54:06 UTC
When an OO document file that is stored at a path that contains non-ASCII characters, is opened from a shell (Windows Explorer, Total Commander etc.), a following "save as" operation suggests a wrong path. Instead of the path where the file was opened from, the path of the last used file open or save dialog is offered. If the file is opened from within OO using the file open dialog, this error doesn't show - probably because the last recently used dialog already used exactly the right folder. Steps to reproduce: - put any OO document into (say) E:\test\ascii\ - open this document, and save it using "file"/"save as" with another name - put any OO document into (say) E:\test\ü-not-ascii\ - open that second document by using Windows Explorer or any other shell (double click on the document file) - select "file"/"save as" Expected behaviour: The "save as" dialog should default to the path "E:\test\ü-not-ascii". Observed behaviour: The "save as" dialog defaults to the path "E:\test\ascii". This bug apparently applies to all OO document types (I tested with Writer, Calc and Draw) and was also present in 4.1.3 already. It appears to be perfectly reproducible here (tried it on different machines). Configuration is set to not use OO dialogs (checkbox unchecked). Eventually this bug might be related to bug 56762 and/or bug 98604.
Already reported *** This issue has been marked as a duplicate of issue 69065 ***
This is *NOT* a duplicate of bug 69065. Please read the description carefully. I assume that there is a bug in parsing the command line argument. If the provided path contains a non-ASCII character, parsing is aborted so the path is not remembered as the "current directory". As a consequence, "save as" uses the last known "current directory", which in this case is the last recently used path. This has nothing to do with the "My Dcouments" path. Please also note that the behaviour is correct if the path doesn't contain non-ASCII characters.
Sadly, more than a year and two (minor) releases later, this boring bug is still not fixed. It's still perfectly reproducible in 4.1.6.
JFTR: With version 4.1.7, the problem persists.