0.86: BUG: "Save selection" messes up the file name if it has a dot and overwrites without warning - older versions too
Posted: Sat Jul 15, 2017 2:14 am
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).
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).