Description: The problem occurs in writer and calc. Please consider that I'm using the german version! I want to "save under", enter a file name and change the filter thereafter. By changing the filter it corrupts the entered filename, e.g. in calc I enter "2025.04.06 testdata". The filter has "ods". When I change the filter to "xlxs" and click on "extend filename automatically" it changes the filename to "2025.04.xlxs" When I do this in writer it behaves the same. Steps to Reproduce: 1. it should be fixed 2. 3. Actual Results: See Description Expected Results: No change of the entered filename after changing the filter and click on "extend filename automatically" Reproducible: Always User Profile Reset: Yes Additional Info: I've just described it... Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 20; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE 25.2.2-1 Calc: CL threaded
And what should happen, when the filename box had "2025.04.ods", and you change from ODS to XLSX? Should it become "2025.04.xlsx" or "2025.04.ods.xlsx"? IMO, this is not a bug. The file extension is just any characters after the last dot; and changing the filter, when "Automatic file name extension" is active, there is no bullet-proof way to know, if the last group of characters was meant to be extension or part of the name. Is there an application, that allows to have extension chosen automatically based on the file type, which does that in a way that you want? We could consider that app's behavior as a potential guideline.
As a potential improvement, the "Automatic file name extension" function could consider the *previous* filter, when deciding if the new extension should be appended to the whole filename, or it should replace the section after the last dot. It could be modified to only replace the section that matches one of the extensions registered for the old filter. The (potential) code pointer is lcl_autoUpdateFileExtension in fpicker/source/office/iodlg.cxx. But IMO, a clear specification of the wanted behavior is needed; asking for UX eval.
(In reply to Mike Kaganski from comment #2) > ... could be modified to only replace the section that > matches one of the extensions registered for the old filter. IOW, only xlxs, csv, html etc. in the name is replaced and any foo, bar, baz will be ignored. I see no harm in this modification, the file naming with dots between date sounds common.
(In reply to Mike Kaganski from comment #1) > And what should happen, when the filename box had "2025.04.ods", and you > change from ODS to XLSX? Should it become "2025.04.xlsx" or > "2025.04.ods.xlsx"? > > IMO, this is not a bug. The file extension is just any characters after the > last dot; and changing the filter, when "Automatic file name extension" is > active, there is no bullet-proof way to know, if the last group of > characters was meant to be extension or part of the name. > > Is there an application, that allows to have extension chosen automatically > based on the file type, which does that in a way that you want? We could > consider that app's behavior as a potential guideline. Hey Mike, sorry for my late reply. I think you did not understand my problem: The file name "2025.04.06 testdata" is changed to only "2025.04.ods" that means the part ".06 testdata" is missed!!! And this change is made when I change the filter... So the origin name of the file must be edited thereafter. And what I expect should be "2025.04.06 testdate.xlxs"
(In reply to Joachim Urmersbach from comment #4) > I think you did not understand my > problem: The file name "2025.04.06 testdata" is changed to only > "2025.04.ods" that means the part ".06 testdata" is missed!!! To the contrary: I understood your problem, but you didn't understand me: from the application point of view, the last part of the file name after last dot is called "file extension". File extension is often three characters (.TXT); it is also often four characters (.DOCX); but it may be arbitrary - and even with spaces. So in your "2025.04.06 testdata", only human can definitely tell, that "06 testdata" is *not* an extension. From application's point of view, when you change file type, the application needs to decide, *why* it *should* change text like "2025.04.ODS" into "2025.04.XLSX" (i.e., replace the part after the last dot), but "2025.04.06 testdata" into "2025.04.06 testdata.XLSX" (i.e., keep the part after the last dot). As I explained in comment 2, there is a viable heuristic that we could use; but that's a heuristic, and comment 1 discusses the original problem that that heuristic could improve.
My expectation would be: - I have given a filename, the extension is not mentioned in the name!!! - the standard extension is odt or ods - I change the filter to xlxs - the filename is never allowed to be changed, whatever the name is and also if there are dots in the name or not. Because the extension is never shown in the filed of the name! So why do you think it is correct behavior to think about and decide whether the part after the dots given in the name mark the beginning of the extension? This is not logical in my opinion...
(In reply to Joachim Urmersbach from comment #6) > My expectation would be: > > - I have given a filename, the extension is not mentioned in the name!!! > - the standard extension is odt or ods > - I change the filter to xlxs > - the filename is never allowed to be changed, whatever the name is and also > if there are dots in the name or not. Because the extension is never shown > in the filed of the name! Your expectation is understood. Comment2 and comment 3 are discussing how we can make that happen. > So why do you think it is correct behavior to think about and decide whether > the part after the dots given in the name mark the beginning of the > extension? Because "the standard extension is odt or ods" is only some *usual convention*, not a law. People call their files very differently; they use "wrong" extensions (like "XLS" for CSV), or completely custom extensions, in their practice. So again: while I myself suggest, that we can improve, by following these "common conventions" (again, see comment 2), I repeat that ".06 testdata" is a *valid extension*, and honestly, the current behavior is technically correct and logical.