1.0: "Delete original" should skip when file creation failed

[f2d]

Hi.

XnView: MP 1.0 64-bit (Apr 28 2022)
OS: Windows 10 64-bit

Effect: if source file can be read, but new file cannot be created, original is deleted anyway.

To reproduce:

1. Open "Batch convert" (Ctrl+U).
2. Output to "Source folder".
3. Enable "Delete original".
4. Input:
   
   • (a) "Add folder" that contains files with full path longer than 255+ characters.
     For example, 266 characters:

     Code: Select all

     D:\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\12345678901234567890123456789012345678901234567890\test.png

     Note: only "Add folder" reproduces the bug.
     When I drag&drop to batch input, or drag&drop to viewer and Ctrl+U from there, short 8.3 names are used instead.

     Code: Select all

     D:\123456~1\123456~1\123456~1\123456~1\123456~1\test_1.png : saved

   • (b) Add input files with unicode filename and use output format with plugin.
     For example, output to QOI with https://github.com/pfusik/qoi-ci
     I reported this in https://github.com/pfusik/qoi-ci/issues/8 and was told that it is limitation of XnView plugins, that get question mark characters instead of unicode in paths.
5. Run batch convert.

Actual behaviour (bug): original is deleted after new file was not created.
Example status report:

Code: Select all

D:\★.png : loading
D:\★.png 456x456x1 : loaded
D:\★.qoi : not a picture

Input files: 1
Extracted pages: 1
New files: 1

Note that "New files: 1", but new file does not exist.

Expected behaviour: new valid file is created, old file is deleted.
Or: no new valid file, old file is kept.

Whatever the underlying causes (which are separate problems), original file should be kept if creation failed.

I personally understand that "Delete original" is dangerous, and only use it to save operational disk space when I have original files in a backup, and I check my results and file counts to match that. Otherwise I keep original files and delete them manually after checking results, if ever.

[helmut]

Thank you for reporting this one, f2d. Setting "Delete original" is indeed a bit dangerous but software (here: XnView) must minimize the risk of loosing anything to zero. This problem should be fixed with high priority, I think.

[xnview]

do you have the problem only with QOI plugin?

[f2d]

do you have the problem only with QOI plugin?

With method (b) - unicode paths - I did not try every available file type.
QOI plugin (qoi-ci, using "Xqoi.usr" file) is the only plugin that I know has this problem, and the only user-installed one I have.
Aside from configs and DB files, everything else I have in XnView MP is from its default setup.

The other method (a) - add folder with overly long paths inside - was reproduced with PNG source saved to PNG, and probably fails to create any files in Windows.
Again, I did not try saving every available file type with this method too.

[Scargoth]

Bonjour, j'ai eu du mal à trouver un post qui traite déjà de ce problème pour éviter d'ouvrir un "nouveau bug" de plus.
Il me semble quil s'agit du même problème, bien qu'il soit apparemment traité ici "en ligne de commande" ?
1- sélectionner un fichier avec un nom très long
"Fichier avec un nom très (voire beaucoup trop)long, qui excède le raisonnable, mais qui a été généré de façon sans doute automatique et qui avait quand même été accepté par le système, et même XnView le merveilleux!.webp" (215 caractères sans l'extension ; 72 caractères au total pour le nom complet du dossier)
2- Ctrl+U (Outil/Conversion par lot...)
2- sortie : Dossier source
3- Nom de fichier : {Filename}
4- Supprimer l'original Coché

==> Erreur lors de la création du fichier, mais l'original est supprimé (heureusement, il est allé dans la corbeille...)



---------------------------
Hello, I had trouble finding a post that already deals with this problem to avoid opening a "new bug".
It seems to me that it is the same problem, although it is apparently treated here "in command line"?
1- select a file with a very long name
"File with a very (or even much too) long name, which exceeds the reasonable, but which was generated probably automatically and which had been accepted by the system anyway, and even XnView the wonderful!.webp" (215 characters without the extension; 72 characters in total for the complete name of the file)
2- Ctrl+U (Tool/Batch conversion...)
2- Output: Source folder
3- File name: {Filename}
4- Delete original Checked

==> Error when creating the file, but the original is deleted (fortunately, it went into the recycle garbage can...)

[xnview]

I've tried with a pathname of 280 chars and no problem, do you use multi core?