Bug 111071 - VistaFilePickerImpl() behavior is not consistent when saving with unknown file extension
Summary: VistaFilePickerImpl() behavior is not consistent when saving with unknown fil...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError
Depends on:
Blocks: LO-File-Dialog File-Dialog
  Show dependency treegraph
 
Reported: 2017-08-01 22:31 UTC by Aron Budea
Modified: 2019-01-17 19:53 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-08-01 22:31:09 UTC
For clarification, "unknown file extension" is anything that's after the last period in the file name, not necessarily an actual file extension. Users often add dates or versions to file name, sometimes delimited by dots.

Normally the files end in an actual extension, but if not, it can cause subsequent issues.

- Save a file with the name "abcd.12" in Writer.

=> ".odt" is correctly added as extension, which is good.

- Rename the file to "abcd.12" in the OS.
- Save a file with the name "abcd.12" in Writer in the same directory.

=> There is a confirmation dialog for overwriting the existing "abcd.12" file, so ".odt" is not added in this case, which is inconsistent.

In Windows there's a checkbox in the save dialog, "Automatic file name extension" that wasn't touched, and was checked in both cases.

Observed with LO 5.4.0.3 & 3.3.0 / Windows 7.
Comment 1 m.a.riosv 2017-08-02 08:28:11 UTC
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.
Comment 2 Aron Budea 2017-08-02 14:08:47 UTC
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".
Comment 3 Yousuf Philips (jay) (retired) 2017-08-02 14:53:03 UTC
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.
Comment 4 Aron Budea 2017-08-02 15:07:46 UTC
(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.
Comment 5 Yousuf Philips (jay) (retired) 2017-08-02 15:29:01 UTC
(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.
Comment 6 Aron Budea 2017-08-02 15:38:27 UTC
(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.
Comment 7 Yousuf Philips (jay) (retired) 2017-08-02 16:50:01 UTC
(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.
Comment 8 Aron Budea 2017-08-02 18:32:52 UTC
(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).
Comment 9 Yousuf Philips (jay) (retired) 2017-08-02 22:41:08 UTC
(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.
Comment 10 Aron Budea 2017-08-03 03:35:00 UTC
(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.
Comment 11 Xisco Faulí 2018-11-26 19:08:44 UTC
Dear Aron Budea,
Do you still reproduce this issue on master ?
Comment 12 Lars Jødal 2018-12-28 11:39:40 UTC
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.
Comment 13 Heiko Tietze 2018-12-30 11:45:47 UTC
Adding this to the agenda for the design meeting. I agree with WFM as Jay commented in c3.
Comment 14 Roman Kuznetsov 2019-01-16 17:50:55 UTC
(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
Comment 15 Cor Nouws 2019-01-17 13:21:24 UTC
(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.
Comment 16 Heiko Tietze 2019-01-17 14:38:57 UTC
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?
Comment 17 Lars Jødal 2019-01-17 15:27:36 UTC
(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.
Comment 18 Heiko Tietze 2019-01-17 15:50:37 UTC
(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.)
Comment 19 Lars Jødal 2019-01-17 19:10:37 UTC
(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.
Comment 20 V Stuart Foote 2019-01-17 19:53:57 UTC
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?