This is an incredibly annoying bug -- I actually registered just to report this one. I suppose most developers don't use this feature on a regular basis, or there would certainly be more interest in fixing this, if there was more dogfooding on this one.

[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

Confirmed for libreoffice 3.5.0beta2, linux32, ubuntu 10.04

This bug is present in pretty much all "save as" or "file open" dialogs. It's old: already existed in early openoffice.org versions.  I'll open a separate bug for different dialogs if that is better - please let me know.  Below are a couple of cases that exhibit similar behaviour: LibreOffice remembers the last used directory for a certain action, which is very often the WRONG directory.  It would be better, in my opinion, to start from the directory of the current document OR the current working directory when libreoffice was started from the commandline.

Alternatively, it would make sense to only remember these folders during a session and forget them when the program is closed.  Or, make it optional.


Examples (I'm sure there are more):

1) File/open dialogs (for instance: insert picture from file) remember the last  directory from which I have inserted a picture. Very often this has nothing to do with the current document. It takes a lot of effort to navigate back to the folder where the current document is.

I suggest in this case to use the folder of the currently opened document as a
starting point opening new files such as images.  Possibly, after this folder has been changed _within the current session_, it could be remembered for the current document.  

2) File->Open does a similar thing, but it remembers a DIFFERENT directory than insert->picture->from file.

3) file->save on a new document has a similar problem when started from commandline: go to directory a/b/c, start libreoffice (new document), save -> suggests home directory instead of a/b/c

4*) "File->Save As" DOES show the proper behaviour, starting at the current document's directory. It does not remember the last selected dir, apparently.

That last point (4*) should have read:

"File->Save As" DOES show the proper behaviour when saving an existing document with a different name: it starts at the current document's directory.

I completely agree with Hein Zelle.. I'll test LibOO 3.5Beta2 soon

Is there any update on this one? It's been more than two years...

*** Bug 51149 has been marked as a duplicate of this bug. ***

*** Bug 48152 has been marked as a duplicate of this bug. ***

*** Bug 66996 has been marked as a duplicate of this bug. ***

*** Bug 67222 has been marked as a duplicate of this bug. ***

Strange... When I do 
File > Export as PDF, it does 100% of the times always and since ages give the same path (and name) as the docuent that I export.

So.. interesting to find out what is going on in the other situations, reported here...

*** Bug 67000 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> I suppose most developers don't use this feature on a regular
> basis, or there would certainly be more interest in fixing this, if there
> was more dogfooding on this one.

While this request undoubtedly deserves proper attention, and I don't question that there are scenarios where the current behaviour is not optimal, I only want to describe the opposite scenario: when the current state is the desired one.

Our organisation produces documentation for customers as PDFs. Each documentation set may consist of tens or hundreds of documents, and they are initially prepared as ODFs in a structured directory tree. When the final PDFs are created, they go to another dedicated output directory (on another server). It would be pain, if we needed to browse there for each document. The best is to browse there once (for first document), and then all subsequent PDFs go there, regardless of the ODF path. This is not restricted to one document, or one LO session.

What I want to stress is that this may only be fixed by introducing a new option in settings, because simple change of the way it works, without a choice, will hurt other users.

*** Bug 69880 has been marked as a duplicate of this bug. ***

*** Bug 71968 has been marked as a duplicate of this bug. ***

As I suggested in #71968 (sorry for duplicate) there should be a button on the Export dialog with the following label:

"Navigate to document's folder"

The dialog should work as it is working now. That is, it should offer by default the folder in which the last pdf was saved. But the mentioned button could save us from navigating to the folder in which the ODT file is.

Or, the opposite solution can be also good. It could offer by default the folder in which the ODT file is and a "Navigate to last pdf exporting directory" button could navigate into the folder in which I exported my last pdf file.

(In reply to comment #17)

>              It could offer by default the
> folder in which the ODT file is and a ....


Must be a Windows-only issue?

For me, File > Export to PDF always gives the location of the actual file ..

For me it depends whether or not there is already a PDF in the target directory. So depending on this sometimes it suggests the same directory as the one the document is residing in; at other times it suggests the directory I last saved a pdf to.

Created attachment 99851 [details]
attachment-10306-0.html

Am 26.05.2014 09:32, schrieb bugzilla-daemon@freedesktop.org:
>
> *Comment # 19 <https://bugs.freedesktop.org/show_bug.cgi?id=34303#c19> 
> on bug 34303 <https://bugs.freedesktop.org/show_bug.cgi?id=34303> from 
> Alexander Mueller <mailto:xelarellum@web.de> *
> For me it depends whether or not there is already a PDF in the target
> directory. So depending on this sometimes it suggests the same directory as the
> one the document is residing in; at other times it suggests the directory I
> last saved a pdf to.
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You are on the CC list for the bug.
>

I prefere the same directory as the one the document is residing in.

Created attachment 99852 [details]
attachment-10306-1.dat

Created attachment 99853 [details]
klaus_w_posner.vcf

- In many cases it is very convenient if the previous directory is offered as default, where the last pdf was saved. 
- In many other cases it's better to have the same directory where the odt (or whatever original file) is. 

That's why I suggested to offer the last pdf-exporting directory as default (this is the present behaviour) and have a "Navigate to the document's directory" button.

So this is a bug on Windows (I  can't check)

For comment #14, Mike (and others about the same): I understand the idea. Pls file an enhancement for that.

With version 4.3.0.4, windows XP SP3, I do not reproduce this issue.
Export to pdf always save to the original document dir.

Maybe this is fixed already? Could someone check?

P.S.: I added Klaus Langguth to cc list of this bug. He claimed this same bug behaviour on MAB4.2.

(In reply to comment #25)

Please ignore my comment in #25. I reproduce this in Windows 7, LibreOffice 4.3.1.1.

Set version to 4.3.0.4, as there is no 4.3.1.1 in the list.
Someone should set it to an earlier version when confirm it's reproducible in that version.

Per bug 71968, set version to 4.0.4.2.

I can confirm this bug. It seems to me the problem is specific for VistaFilePickerImpl. It does not happen on Windows XP neither with internal LibreOffice file picker.

Also, this is not specific to PDF. Command File|Export does not set directory to document's directory either.

(In reply to pavel.lastovicka from comment #29)
> I can confirm this bug. It seems to me the problem is specific for
> VistaFilePickerImpl. It does not happen on Windows XP neither with internal
> LibreOffice file picker.
> 
> Also, this is not specific to PDF. Command File|Export does not set
> directory to document's directory either.

That would suggest a duplicate of bug 37814 (as I would have assumed from the previous comments, too), but I got private mail lately that claims that this export-to-PDF--specific wrong-save-as-dir issue is /not/ solved with recent LO nightlies that /do/ contain a fix for the general wrong-save-as-dir in case of non-ASCII characters bug 37814.