Not saving a new file but replacing one, so what you want implies modify the name on the file system, what LibreOffice must not to do in any way. Or you mean create a new one the extension, but then it is not replace.

I wouldn't want to modify the existing file, but I'd expect LO to add the extension automatically, and thus not ask about replacing (and then replace) the existing file that now wouldn't have the same name anyway.

Basically, if there is a file named "abcd.12" on the disk, and you save a file named "abcd.12" when "Automatic file name extension" is checked, LO should have no business with the existing file named "abcd.12": it attempts to save "abcd.12.odt".

I think the behaviour is correct that if a file exists in the folder of the same name that it would overwrite it and if there wasnt an existing file that it would append the correct file extension.

This would be no different if a user double-clicked on the filename in the file list grid or typed the exact name in the filename field.

(In reply to Yousuf Philips (jay) from comment #3)
> This would be no different if a user double-clicked on the filename in the
> file list grid or typed the exact name in the filename field.

At least in Windows the file type dropdown restricts the files shown in the list to that extension, so it's not possible to double-click on a file with different extension.

(In reply to Aron Budea from comment #4)
> At least in Windows the file type dropdown restricts the files shown in the
> list to that extension, so it's not possible to double-click on a file with
> different extension.

Even if you cant see the file because of the dropdown restrictions of file type that doesnt change that the does file exists.

(In reply to Yousuf Philips (jay) from comment #5)
> Even if you cant see the file because of the dropdown restrictions of file
> type that doesnt change that the does file exists.

The file that you mean as exists isn't supposed to be considered. The file with the correct extension added is supposed to be considered instead.

(In reply to Aron Budea from comment #6)
> The file that you mean as exists isn't supposed to be considered. The file
> with the correct extension added is supposed to be considered instead.

Of course it should be considered, even if it isnt listed due to what is selected in filetype. Imagine this

1. Open Writer
2. Ctrl + S
3. type 'test' and it saves it as 'test.odt'
4. Ctrl + Shift + S
5. 'test' appears in text field
6. Change filetype to 'docx'
7. type '.odt' at the end of the name and press enter

At this point, the file dialog asks if 'test.odt' should be overwrite and the filetype has changed to ODF, atleast on Linux, and when i say yes, it overwrites the file.

(In reply to Yousuf Philips (jay) from comment #7)
> At this point, the file dialog asks if 'test.odt' should be overwrite and
> the filetype has changed to ODF, atleast on Linux, and when i say yes, it
> overwrites the file.

Please see comment 2, especially the second paragraph.
Linux doesn't have that setting currently, and therefore its behavior is acceptable (ultimately having the same settings and behavior in both systems would be desirable, but for that the dialogs would have to be unified).

(In reply to Aron Budea from comment #8)
> Please see comment 2, especially the second paragraph.

Read it again and i can see different users wanting different things and you cant please everyone. Should LO overwrite a user's choice of file extension after they explicitly decided it should be something else? I would say no.

> Linux doesn't have that setting currently, and therefore its behavior is
> acceptable (ultimately having the same settings and behavior in both systems
> would be desirable, but for that the dialogs would have to be unified).

Yes linux doesnt have the checkbox visible, but it automatically appends the correct extension to the filename when you do change the filetype entry.

(In reply to Yousuf Philips (jay) from comment #9)
> Read it again and i can see different users wanting different things and you
> cant please everyone. Should LO overwrite a user's choice of file extension
> after they explicitly decided it should be something else? I would say no.

Note, by unknown file extension I mean the final dot-delimited piece of file name that isn't an actual file extensions (see example "abcd.12"). What you're referring to here is actually bug 111070, let's keep them separate.

Dear Aron Budea,
Do you still reproduce this issue on master ?

I can confirm the behaviour with current fresh version:

Version: 6.1.4.2 (x64)
Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3
CPU tråde: 4; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: GL; 
Lokalisering: da-DK (da_DK); Calc: group threaded

and also with a quite recent master version:

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 3c964980da07892a02d5ac721d80558c459532d0
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-12-12_03:38:09
Locale: da-DK (da_DK); UI-Language: en-US
Calc: threaded

I also agree that this should be considered a bug, not a feature: 

a) "Automatic file name extension" is checked and file type is chosen (e.g. "ODF Text Document (*.odt)" or "Word 2007-2019 (*.docx)"). But yet, Writer tries to save the file as a file of type .12 instead of the chosen filetype.

b) As Aron's headline says, behaviour is not consistent. If no file "abcd.12" exists, then saving with the exact same settings saves the file as "abcd.12.odt". Thus, ".odt" is added in the normal case, but not if the file "abcd.12" already exists. I agree with comment #2 about expected behaviour.

Adding this to the agenda for the design meeting. I agree with WFM as Jay commented in c3.

(In reply to Heiko Tietze from comment #13)
> Adding this to the agenda for the design meeting. I agree with WFM as Jay
> commented in c3.

I don't agree. It's a bug, because option "Automatic file name extension" was active! And extension should be added to file name anyway in this case

(In reply to Aron Budea from comment #0)

> In Windows there's a checkbox in the save dialog, "Automatic file name
> extension" ... 

Same too in LibreOffice with the famous and great internal dialogs.

We discussed this topic in the design meeting. While it's true that saving a new file adds the extension and changing it at the OS level doesn't, which is a clear WFM things on Windows are different (as long we have the internal dialog also on other OS). If the checkbox "Automatic file name extension" is there it's setting has to be respected, meaning a file Test.odt.123 renamed on the OS level to Test.odt.123 get's another odt extension. Maybe we just drop the option?

(In reply to Heiko Tietze from comment #16)
> [...] If the checkbox "Automatic file name extension" is
> there it's setting has to be respected, meaning a file Test.odt.123 renamed
> on the OS level to Test.odt.123 get's another odt extension. Maybe we just
> drop the option?

First, I hope the feature "Automatic file name extension" is kept. If not, I will have to manually add .odt every time I save a Writer file, or it will have no extension and not be recognized by Windows as a Writer file. (If this is not what you are suggesting, please enlighten me!) Like it or not, Windows recognize file associations only from the extension.

Second, the example Test.odt.123 is not representative of the example given in the original bug report. The example from the original bug report renamed the extension of the original file, not because this was especially meaningful, but to create a file with an extension that might be used by a user for version-tracking.

Let me try to give a semi-realistic example.

Suppose a file myfile.12 exists already. This file may be completely unrelated to the Writer document that I am working on. The document I am working, I am saving in a number of versions:
First version: "Save as", name given by me is "myfile.1", saved as myfile.1.odt
Second version: "Save as", name given "myfile.2", saved as myfile.2.odt
...
Twelvth version: "Save as", name given "myfile.12". Since a file with the full name myfile.12 exists already in the chosen directory, Writer will not save the file as myfile.12.odt, but ask the user if the existing file should be overwritten. If the user confirms (likely due to confusion), then the original, unrelated file myfile.12 will be overwritten by the Writer document. Afterwards, the user will have lost the original file myfile.12, and may even later have problems finding the Writer document myfile.12, since the extension "12" does not relate it to Writer.

Does this make sense - as description and as an example of why this is not desired?

And yes, should somebody for some reason save a Writer file and give file name as Test.odt.123 while having checked "Automatic file name extension", then in my humble opinion, the logical thing to do would be to save with the name Test.odt.123.odt - it is a Writer file saved in odt format. 
Should somebody for some reason want to save the a Writer file with the full name Test.odt.123, then they are free to do so, they just need to uncheck "Automatic file name extension" before saving.

(In reply to Lars Jødal from comment #17)
> First, I hope the feature "Automatic file name extension" is kept. If not, I
> will have to manually add .odt every time I save a Writer file...

Why not have the auto extension on by default? Normally, you have to enter the filename in brackets ("test.123") to definitely use this extension. Isn't this the default on Windows?

> Does this make sense - as description and as an example of why this is not
> desired?

Sounds like a good example. But don't we talk about test.12.odt?


(Let's not go too far with the discussion. We agree more or less on the bug and hope for the best regarding the implementation.)

(In reply to Heiko Tietze from comment #18)

> Why not have the auto extension on by default?
It is already on by default - which is fine.

> Normally, you have to enter
> the filename in brackets ("test.123") to definitely use this extension.
> Isn't this the default on Windows?
Ah, I was not aware of that. My description in comment #17 did not take this into account. Perhaps everybody can then be happy! I suggest the following behaviour for "Save as":

a) Filename given as Test.123: The file is saved as Test.123.odt if automatic filename extension is checked, and as Test.123 if not.

b) Filename given as "Test.123": By giving quotation marks, the user specifies that this is the exact filename, so the file is saved as Test.123, even if automatic filename extension is checked. 

The choice of name should be independent of whether or not a file of the name Test.123 already exists in the directory. As now, the user should be warned before an existing file is overwritten, and the binary format of the saved data should be that chosen in the "Save as" dialogue (e.g. ODT format or DOCX format).

To me, such behaviour would seem to be both consistent and flexible.

Wait, wait! 

The mismatched handling of abcd.12 vs abcd.12.odt of OPs comment 0 STR does not occur when the LibreOffice internal file picker is used--just with the marginal VistaFilePicker() used when a "UseSystemFileDialog" is set True, as is current default.

Points to a logic error in matching existing file string (in Windows that means with any extension--including no extension) against the save action.

Rather seems this is an implementation error in the "native" VistaFilePickerImpl()

@Mike K, Jan-Marek -- what is your take?

MS Word 2016 always adds the extension according to the selected file type: if I choose "Word Document (*.docx)", and type "file.doc", I get "file.doc.docx" (ref: tdf#111070); if I type "file.12", I get "file.12.docx" - as if there's "Automatic file name extension" checked.

It does that *even when there's a file named file.doc or file.12* in the directory; and it does *not* warn. So first of all, I agree that we must behave likewise; and second, it's likely that we have it implemented wrong (or at least need to handle it differently).

The behaviour is still reproduced with LO 7.3.4.2 on Windows 10.

Version: 7.3.4.2 (x64) / LibreOffice Community
Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: CL

I still think the behaviour proposed behaviour in comment #19 will be consistent and flexible (and intuitive). And it will be consistent with how MS Word behaves, see Mike's comment #21.