#65 Undefined behavior when setting input file and output file to the same filename

[tsftd]

First off, thanks for making a great program! Been using it for years, and only ran across this bug during writing an automation tool which runs several png optimization programs sequentially on a set of files.

While I now realize that you're intended to use the -ow flag for this functionality, there is nevertheless a bug:

1) (defined behavior): When using the same filename for input and output, IF bytes were saved or -force is specified, pngcrush throws an error (pngcrush: cannot overwrite input file *.png) -- which will lead the user to discover the -ow flag (as I did).

2) (undefined behavior): When using the same filename for input and output, IF 0 bytes were saved and -force is not specified, pngcrush does not throw an error, but the input file is overwritten to 0 bytes.

Resolution:

A) Pngcrush should throw the same error in case 2 as in case 1.
B) Pngcrush should check if [input filename] == [output filename] and error out immediately (improving the behavior of case 1 and fixing the undefined behavior of case 2 as well).
C) Pngcrush should check if [input filename] == [output filename] and discard the output option while applying "-ow" automagically.

I should think that case A is minimal expected behavior, case B is improved insofar as it saves the user the time of running pngcrush and then finding out they need to run it again with different options, and case C is optimal, albeit it requires the dev to hand-hold the user.

[tsftd]

Edit: Upon further testing, this only happens to some files. I can't discern any determining characteristics, but attached is one of the files which causes the error as above (simply use [pngcrush "FS_prismcircuit.png" "FS_prismcircuit.png"] to generate the undefined behavior)

version:
pngcrush 1.7.82, uses libpng 1.6.16 and zlib 1.2.8

Further edit: After implementing -ow, another bug was exposed. Unfortunately, running multiple instances of pngcrush with the -ow flag results in one of the files not being outputted. Reproducible on my system with 7 instances. Given that outputting to another file and renaming afterwards (my current workaround) does not trigger it, it's likely that this bug lies in the usage of the temporary file pngcrush generates when it runs. One or more instances probably stomp each other, resulting in the temporary file disappearing and thus no file being outputted. Outputting to another filename (apparently) doesn't use a temporary file, and thus avoids the issue.

[Glenn Randers-Pehrson]

Thanks for the report.

Pngcrush does try to disallow overwriting a file when -ow is not present, but that doesn't work well on all operating systems. What OS are you using?

The -ow option uses "pngout.png" as its temporary file, so if you run several instances of "pngcrush -ow ..." they will stomp on each other's output. If you are doing that, you should specify the temporary file to use, e.g.,

pngcrush -ow [other options] filename.png pngcrush-$$.png

Note that your temporary file must be on the same filesystem as your input file.

[tsftd]

Windows 8.1 x64

Ah, I see, I didn't realize that -ow and outfile would work together like that. Maybe changing "-ow (Overwrite)" to "-ow (Overwrite infile.png with outfile.png or tempfile 'pngcrush.png')" or something similar for the options description would help others avoid my misunderstanding?

[Glenn Randers-Pehrson]

I've added another line to the usage section that shows how to
use "-ow".