0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions too

Reported bugs that have been closed and/or resolved

Moderators: XnTriq, helmut, xnview, Dreamer

Post Reply
User avatar
xnviocumo
Posts: 13
Joined: Mon Oct 17, 2016 12:11 pm

0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions too

Post by xnviocumo »

Bug: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions too

This bug is not new and is not exclusive to current release (0.86) of XnViewMP.

Steps to reproduce:

1. Open any jpg file which filename includes a dot ('.') somewhere in the middle, in addition to the normal '.jpg' extension. (Note that the problem may also be happening with other image file extensions too).
Our example:

some.filename_01.jpg

2. Drag a selection rectangle on any area of the picture.

3. Click F6 (or whatever shortcut you have defined for "File -> Save selection").

4. In the Save File dialog that pops up, in the "Name:" field, you see the original file name without extension. Note that only the substring before the first dot is selected. Place the cursor at the end of the file name, and type anything, for example "-A":

In our example, the Save File "Name:" displays "some.filename_01". Place the cursor after the "1", and append "-A" so the name is now "some.filename_01-A"

5. Click the "Save" button. The dialog closes.

6. Browse to the directory where you save the file, and verify that the new file was (wrongly!) created with the name "some.jpg"

7. If you repeat all from the begining with another file that includes a dot in the middle of the name, the new file will ALSO be saved with the name "some.jpg" no matter what you appended to the original file, and will OVERWRITE the existing "some.jpg" file without any warning.

Expected behavior:

1. The "Save File" dialog shows as suggestion the original file name, without the extension, which is helpful because one can just append something to it. (This is current behaviour except only the part of the string before the first dot is selected).

2. If we append something to the original filename (without any extension) and click Save, a new file is created with the exact name that was entered, PLUS the extension if user didn't typed it. If there would be any existing file with the same name, the program should display a warning message and not overwrite it unless the user confirms so (perhaps with a checkmark to remember this decision?).

NOTE:
The problem seems to be consequence of the program assuming that file names should not have dots in the middle of the name, and use only one dot to delimit the extension. This is not good, because sometimes filenames do have dots in the middle and we cannot be renaming every single file if its has a dot in it. It would seem that the problem is a poor algorithm for detecting the extension, which would just take anything after the first dot as the extension, when it should probably be the opposite, i.e., take the bit after the last dot, for example.

My system:
Kubuntu Linux 16.04
XnViewMP 0.86 (but this bug is present since various versions ago, including at least 0.84 and 0.85).
User avatar
xnviocumo
Posts: 13
Joined: Mon Oct 17, 2016 12:11 pm

0.86 and 0.87: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning

Post by xnviocumo »

Dear devs,
Thank you for the amazing 0.87 release with tons of bug fixes!

I have tested 0.87 for the bug in this thread and unfortunately the bug is still present in this release.

I know you are extremely busy, and I wouldn't dare to comment on your priorities, but could you please at least post just a few words about this bug? Is there any special reason why you haven't made any comments about this issue? Is anything wrong in my report that I could improve? Could I help in any way?

I have spent a significant time testing, so please just a simple "thanks", or "we'll have a look" or whatever would do a long way to keep me motivated to help. In the meantime, I'll make a post about this issue for version 0.87, to keep users aware.

Thanks again for this great software!
User avatar
xnview
Author of XnView
Posts: 43326
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.86 and 0.87: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning

Post by xnview »

O.k., thank you, I can also reproduce the problem. Issue 1302 is fixed in next version.

(And sorry about the delay to check the bug)
Pierre.
User avatar
xnviocumo
Posts: 13
Joined: Mon Oct 17, 2016 12:11 pm

Re: 0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions

Post by xnviocumo »

Dear Pierre,
Thank you so much for your reply. Please let me assure that I understand and respect how busy you certainly are. Once again, my word of appreciation for all the hard work and passion you put to make this amazing piece of software, and with such high level of quality.
User avatar
xnview
Author of XnView
Posts: 43326
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions

Post by xnview »

This problem is supposed to be fixed in XnView MP 0.88. Please check and confirm the bug fix here.
Pierre.
User avatar
xnviocumo
Posts: 13
Joined: Mon Oct 17, 2016 12:11 pm

Re: 0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions

Post by xnviocumo »

Thank you Pierre.

I have tested the scenario in the above report and the renaming is correct. So, in a file named some.filename_01.jpg, I made a selection and tried to save it as explained, and the result was some.filename_01-A.jpg as expected. I also tried this: the original file is this time a .png file, named some.filename_02.png. I did the same steps above, this time appending '.jpg' instead of '-A', and the result was as expected: some.filename_02.jpg.png. The "Save File" dialog had automatically selected 'PNG - Portable Network Graphics' as expected, and it saved the file as .png correctly despite the inclusion of '.jpg'.

I have noticed that the Save File dialog still selects by default the substring only until the last dot it finds, as described in (4) in the report. So, a original file name like some.filename_01.jpg gets selected only 'some', which means if we want to append something to the end, we still have to either click at the end of the file or press the 'End' key of our keyboard to put the cursor at the end of the string, or if we want to replace the whole string, we have to manually select it all first. This is a minor detail, but I wanted to include it here for just for completeness of the report.

The main reported issue, however, is fixed.

Thanks again.
User avatar
xnviocumo
Posts: 13
Joined: Mon Oct 17, 2016 12:11 pm

Re: 0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions

Post by xnviocumo »

Ooops! Bad news: :bugconfirmed:
If you use an existing name, the program will overwrite the existing file without warning.


How to reproduce:
Open the some.filename_01-A.jpg (or whatever pic file), drag a selection and hit F6 (Save selection...). In the Save File dialog, do not change the file name, just hit Save. The file is saved, overwriting the original one without any warning.

Should I open a new bug report?
User avatar
xnview
Author of XnView
Posts: 43326
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions

Post by xnview »

xnviocumo wrote:Ooops! Bad news: :bugconfirmed:
If you use an existing name, the program will overwrite the existing file without warning.


How to reproduce:
Open the some.filename_01-A.jpg (or whatever pic file), drag a selection and hit F6 (Save selection...). In the Save File dialog, do not change the file name, just hit Save. The file is saved, overwriting the original one without any warning.

Should I open a new bug report?
:bugconfirmed: Thanks to your detailed description I can reproduce the problem.
Pierre.
Post Reply