The following was done in Windows, Linux might behave differently. I've had this annoyance recently that when opening files from the command line, and doing a Save as, the dialog would show me the Documents directory instead of where the original file was. For the reproducer, I'm simply clearing the user profile, because the bug might only sporadically occur otherwise, but it was rather persistent for me at the time (just when I was looking for a reproducer, after several different tries, it did end up showing the expected directory without clearing the profile). - Clear user profile, - Open a document from the command line: soffice.exe <file name with location>, - Press Ctrl + Shift + S to Save as... => The default Documents directory is shown in the file picker, instead of the original file's location. Observed using LO 25.8.0.0.alpha0+ (41ab24cecd6ad74312843f113d2faa13259cdb7d) / Windows. This is a regression from the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=22c07826d77adf93ada6e17ed6ac531163dd5059 https://git.libreoffice.org/core/commit/22c07826d77adf93ada6e17ed6ac531163dd5059 author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> 2025-02-13 09:55:04 +0100 committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> 2025-02-13 12:03:19 +0100 tdf#165228 Don't reuse previous path in save dialog
> => The default Documents directory is shown in the file picker, instead of the original file's location. Might be a side effect from the mentioned commit - but that is the expected behavior. When no previous path is found (which is the case with fresh user profile), the default is used in the file picker (Documents directory).
There is the previous path: where the file was opened from. LO must know that, since that's what it used to show. In addition, as I wrote, it happens not only with an empty user profile, that is just to have a straightforward reproducer.
(In reply to Aron Budea from comment #2) > In addition, as I wrote, it happens not only with an empty user profile, > that is just to have a straightforward reproducer. Do you have a reproducer when there is already a recent path saved?
(In reply to Samuel Mehrbrodt (allotropia) from comment #3) > Do you have a reproducer when there is already a recent path saved? Sure, here's one on Windows. Let's start with an empty profile, though, to have a uniform start. I have drive D:\, and an ODT/ODS/ODP each in the root directory there. For each, I do: 1. Open with: soffice.exe <D:\filename.ext> 2. Press Ctrl+Shift+S to Save as... (this will open Windows Documents folder by default), save them in the same directory with a different name 3. Open the newly saved file with: soffice.exe <D:\newfilename.ext> 4/a. Press Ctrl+Shift+S to open Save as... file picker 4/b. Press Ctrl+O to open Open... file picker. => Once again, both 4/a and 4/b will show Windows Documents folder. My general expectation is that when the files are in a certain directory, if I start LO fresh (so, not from an empty profile, just a new instance), it should show that directory on Open.../Save as.... If LO is already running, and I keep opening files from one directory, but keep saving them to another, maybe there are different considerations what directory to show when opening files and saving them, but keeping showing Windows Documents is definitely not it.
(In reply to Aron Budea from comment #4) > For each, I do: > 1. Open with: soffice.exe <D:\filename.ext> > 2. Press Ctrl+Shift+S to Save as... (this will open Windows Documents folder > by default), save them in the same directory with a different name > 3. Open the newly saved file with: soffice.exe <D:\newfilename.ext> > 4/a. Press Ctrl+Shift+S to open Save as... file picker > 4/b. Press Ctrl+O to open Open... file picker. To clarify, I do these separately, starting LO anew each time and closing it in the end.
> I have drive D:\, and an ODT/ODS/ODP each in the root directory there. Writer, Calc and Impress all have their own configuration for the last save as. So still, what you see is the expected behavior according to the current implementation. What commit 22c07826d77adf93ada6e17ed6ac531163dd5059 changed is just that the last path in the file picker accidentally survived in some cases. This behavior is removed because of the side effect described in bug 165228. If you think the current behavior is wrong or can be improved, feel free to file an enhancement request which can then be checked by UX.
(In reply to Samuel Mehrbrodt (allotropia) from comment #6) > So still, what you see is the expected behavior according to the current > implementation. I can repeat the above steps any number of times, and the directory that comes up is Windows Documents. Sure enough, the config file has this: <item oor:path="/org.openoffice.Office.Common/Misc/FilePickerLastDirectory"><node oor:name="CalcSaveAs" oor:op="replace"><prop oor:name="LastPath" oor:op="fuse"><value>file:///D:/</value></prop></node></item> <item oor:path="/org.openoffice.Office.Common/Misc/FilePickerLastDirectory"><node oor:name="ImpressSaveAs" oor:op="replace"><prop oor:name="LastPath" oor:op="fuse"><value>file:///D:/</value></prop></node></item> <item oor:path="/org.openoffice.Office.Common/Misc/FilePickerLastDirectory"><node oor:name="WriterSaveAs" oor:op="replace"><prop oor:name="LastPath" oor:op="fuse"><value>file:///D:/</value></prop></node></item> But I see Windows Documents in Save as... and Open..., which means the config entries aren't taken into account. > What commit 22c07826d77adf93ada6e17ed6ac531163dd5059 changed is just that > the last path in the file picker accidentally survived in some cases. > This behavior is removed because of the side effect described in bug 165228. The problem is that people may save to PDF at times, but they open and save files all the time, so I'd say users get hit by the issue this change caused more often than by bug 165228.
So I tried again with a fresh master build on Windows 11, but I really cannot reproduce the issue. Can someone else verify this issue? Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fbf053ac8f6983116014d8f24e153304794d1021 CPU threads: 8; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded
Still reproducible with LO 25.8.0.0.alpha0+ (9299d425f3ed941d983f68d6dc1e979b4d4d1060) / Windows. Let's try with these steps, if it's not reproducible with them, please note what you get in the end. Create two different directories, for me that are: [1] D:\first [2] D:\second - Clear user profile, - In Writer, save a new document to directory [1], note: when you open file picker, Documents directory is shown at first, that is expected at this point, - Close document (go back to start center), - In the OS, place a document in [2], eg. copy the document from [1] to [2], - Open the document in [2], - Press Ctrl+Shift+S to Save as..., => In file picker, directory [1] is shown (where the first file was saved to), when it should be [2] (where the second file was opened from).
From my point of view, there are 2 possible workflows, and only a setting will make them both correct. My current workflow is this: I open a folder with some documents, I edit, save and export as PDF, then try to export the PDF to clients. I expect as before that a document will be created in the folder I am in at the moment. So, on half of the screen I have the folder with documents and their PDF, and on the right I have email/WhatsApp in order to drag and drop PDF files. But, with the most recent folder option, the PDF will go to the most recent folder where I have something else, if I have one document in each folder, and I need to export to PDF and send. The folder where I have now the option to export is the most recent one, which is the previous one, not related with what I am doing at the moment. So I have to change the folder in order to export the PDF in the right place. Then, I change the current working folder, and edit another file, and repeat all the steps, and again I have to change the folder where the exported PDF will go.
Created attachment 200095 [details] video testing the bug I have created a video with both behaviors. In the first minute is the old behavior, is very easy, you get the folder where you work. In the last minute, you can see I have to change each time the folder I need to export.
So this works as designed. If there a are other workflows where the current implementation is not ideal, there are two possibilities: 1. Create a macro which does exactly what you want it to do, and replace the current Save/Export/... action with your macro 2. File an enhancement request with a specific proposal what should be changed In any case, this is not a bug and not a regression.
Bug 165917 that is now in assigned state is about subsequent exports. This bug report is about the first save as after opening a file. There's no sensible explanation why that should show a different dirextory, and surely it doesn't "work as designed". Reopening this to make sure it is fixed alongside bug 165917.
FYI: I have the same problem, I mainly face it when Exporting .odt files as .PDF. Very annoying, up until a few weeks ago the system automatically offered the location of the original .odt file for the .PDF, but now it's not working like that anymore. Mine is: Windows 10 Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded
Looking at this in current nightly again: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 736998ccef0bacdd2bbf038c98dacfbe654f1a4d CPU threads: 14; OS: Windows 10 X86_64 (build 19045); UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded comment #0 steps are reproducible even after fix of bug 165917 but, I believe this is the default from Options - Paths - My Documents, which is a way to configure the default save path. comment #4 steps are reproducible too, but I think the reason is the same as above and the expectation is incorrect and the current way makes some sense too. comment #9 steps are reproducible as well. I would say this is a NAB.
Will implement the same behavior as done for bug 165917. https://gerrit.libreoffice.org/c/core/+/184064
(In reply to Samuel Mehrbrodt (allotropia) from comment #16) > Will implement the same behavior as done for bug 165917. > > https://gerrit.libreoffice.org/c/core/+/184064 Sorry, this is the correct link: https://gerrit.libreoffice.org/c/core/+/184542
The previous implementation of "save as" was much better and far more useful!!! I usually work on several files in different sub folders at the same time. Often times I use ctrl+shift+s just for checking the current folder. When I create a different version of a file or want to export a PDF of the current file it is the most logical thing that the "save as" would chose the current folder of the file. If I have different versions of a file in different folders the "save as" dialogue would actually be the most simple way to check the current folder. I don't even find any other way in Libreoffice to check the current directory of a file. So please make it possible to switch to this very reliable function of Libreoffice. Thanks in advance.
*** Bug 166423 has been marked as a duplicate of this bug. ***
*** Bug 166460 has been marked as a duplicate of this bug. ***
*** Bug 166257 has been marked as a duplicate of this bug. ***
*** Bug 166151 has been marked as a duplicate of this bug. ***
*** Bug 166115 has been marked as a duplicate of this bug. ***
Refactoring in 25.8.0 with 3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 [1][2] needs some additional tweaks for Save-as handling, as Samuel proposed in https://gerrit.libreoffice.org/c/core/+/184542 =-ref-= [1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 [2] https://gerrit.libreoffice.org/c/core/+/184062
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5683376d063569368bd7d3036ec6ce725134bb08 tdf#165392 Save as should default to current document directory as well It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 166534 has been marked as a duplicate of this bug. ***