Super irritating: when you have a document open in LibO and you want to use Save As or when you want to generate a pdf the file dialog opens in a directory you used yesterday. This happens only with the Windows native dialogs. The KDE and MacOS dialogs understand that the most logical place to Save As is the directory the respective document is located. Same for creating a pdf: where else than in the same directory as the original. And guess what, when working on a document what would be the most logical directory when you click File Open? Right, the same directory again. I think it would be fair to say that the correct and most useful behavior (as already acknowledged in the KDE and MacOS versions) should be present in the Windows native dialogs version as well. Note: on windows the alternative Libreoffice dialogs do have the correct behavior, but these dialogs lack usability (long paths unreadable / don't fit in the dialog) and look weird and unfamiliar.
IIUC this is now intentional as fixed in see also bug 34303, but related behavior as in bug 129886 (which I guess is a duplicate of this).
bug 34303 suggests as a workaround to use LibO dialogs. And the fix relates to PDF export macro's. However, the problem is both with File Open, Save As, PDF export dialog. In fact the original report was marked enhancement, then changed to bug. And on the most used platform a most annoying one that bug users will encounter every day. The correct behavior as expected by anybody working on more then 1 document at a time is as in the KDE / MAcOS (didn't try gtk) version, the default directory should be the directory the active document is located, and not a recent directory, or a directory used yesterday. But I just tested on the latest and greatest 6.4.3.2. I created in My Documents directory 1 with document1 and directory 2 with document2. I can confirm that with document 1 active, Save As, PDF export, Save Copy with use directory 1 as default, while with document 2 active, Save As, PDF export, Save Copy with use directory 2 as default. That is great! However, with either document 1 or 2 active File Open will always use directory 2 as default. Meh. How hard can it be?. BTW on KDE this will open a directory I used yesterday, so crazy on that platform as well. Also, Insert Picture uses as default: C:\Users\ferry\AppData\Roaming\LibreOffice\4\user\gallery. Really? When you are working on a document would you have all the pictures you want to insert in your working directory, or would you go through the trouble to copy them over to the gallery first? And then on KDE in this case it opens a folder I used a year ago or so. Wow. So I would say the issue is half fixed in 6.4.3.2, I will inform my users on windows to upgrade. But the other half is still inconsistent and annoying. Should I change the bug title to File Open / Insert Picture and mark confirmed?
I found another File Save dialog (in linux): When you have a writer document with an embedded draw object, you can save a copy of the embedded draw object. De default directory is /home/user. Expected: the documents working directory.
Ferry: do you agree to close this as duplicate of bug 129886?
I think this bug report covers more cases: File Open, Save As, PDF export, Insert Picture, save embedded draw object. So, if you ask me, then no. In fact I would like to see it's status changed to confirmed.
Hello Ferry, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Tested with 7.1.6.2 on Windows with Windows dialog boxes. With 2 documents open SaveAs and ExportAsPDF dialogs seem to follow the odt document path as expected. Saving a new previously unsaved document goes to "My Documents", which me is unlogical when I am already working on a document in a certain location. When opening a new document it seems to use the last opened path as default, instead of the path of the current document. So when opening A, the B, then activating A, FileOpen will use directory of B. Why is this annoying? When you are opening documents in response to phone calls each document related to a project in their own working folder. When returning to finish the document, open new ones or save them you want to return to the respective project folder. It's like working on 2 separate projects simultaneously (an I sometimes have 10 documents or more open) and LibO always guesses the working folder wrong.
I now have the same problem with LO 25.2.2.2 (x64). I offers to "saveAs" a document which was opened from an existing not to that folder but to the folder which was last used for saving a document. Whether I use the Windows or the proprietary Save dialogues seems to be irrelevant, now.
(In reply to Andreas Körber from comment #8) > I now have the same problem with LO 25.2.2.2 (x64). I can confirm this issue with LO 24.8.6.2
> I can confirm this issue with LO 24.8.6.2 To me it seems, the original mentioned bug had been eliminated somewhere in the past versions incl. 24.8.5.2. From 24.8.6.2 the bug is back ..... I tested versions 24.8.2.? to 24.8.5.2: Regardless of the dialogs (LO vs. Win) "save as", "print to PDF", etc. use the directory of the current file. From 24.8.6.2 they don't.
And here we are again in 2025 with the same issue. I reported this problem back in version 24.8.6.2, and now I’ve reported it again in version 25.8.0.4. I was using an older version that didn’t have this issue, but I can’t remember which one it was. If anyone could point me to a version where this doesn’t happen, I’d appreciate it, because it seems like there’s no real interest in fixing it—it’s been around for a long time.
(In reply to Iat_Johnny from comment #11) > And here we are again in 2025 with the same issue. I reported this problem > back in version 24.8.6.2, and now I’ve reported it again in version > 25.8.0.4. I was using an older version that didn’t have this issue, but I > can’t remember which one it was. If anyone could point me to a version where > this doesn’t happen, I’d appreciate it, because it seems like there’s no > real interest in fixing it—it’s been around for a long time. I went back to 25.2.3.2
(In reply to Iat_Johnny from comment #11) > can’t remember which one it was. If anyone could point me to a version where > this doesn’t happen, I’d appreciate it, because it seems like there’s no > real interest in fixing it—it’s been around for a long time. FWIW I can confirm this regressed bug as being present in all of the 25.8.x branch up to and including the latest nightly which was 25.8.2.0.0 at time of posting. It is unbelievably disruptive to my keyboard-driven workflow which relies on LibreOffice reliably remembering where files were saved. I did sequential roll-backs until finding a bug-free version, which was 25.2.5. Because 25.2.5 is also the current Previous Release Branch, I've decided this is the push I need to stick with the Previous branches for the foreseeable future. Staying on the bleeding edge is great until it cuts you, and this is the third time I've seen this 'Save As' bug crop up. There's no telling when it might show up again. I'm really hoping this is fixed by the time 25.8.x becomes Previous, and praying that it IS still a bug and not a feature.
Maybe the latest comments are talking about bug 167897 ?
(In reply to Buovjaga from comment #14) > Maybe the latest comments are talking about bug 167897 ? Thanks. I'd missed that, and some of it does sound closer to the current behaviour I'm seeing, but because I regularly use Save As and rarely use Export the results are the same for me. I'd seen reference to Export mentioned on Reddit but the details weren't as clear and I didn't make the connection. At least it does sound as though this is a broken implementation of a new feature, rather than a regression, so there's hope for a fix. In the meantime I'm sticking with 25.2.5.2, but will keep an eye on that other bug's page.