#62 'pngcrush infile outfile' may overwrite file without prompting.

[Zack Weinberg]

I'm forwarding this bug report verbatim from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411033 as I think A. Costa has explained it better than I could have:

I had the bad luck to run 'pngcrush' in a
directory with only two files:

% ls -log
total 32554
-rw-r----- 1 16638693 Jun 14  2005 Jettaradio0001.png
-rw-r----- 1 16562597 Jun 14  2005 Jettaradio0002.png
% pngcrush *
    [...]
   Recompressing Jettaradio0001.png
    [...]
   Best pngcrush method = 9 (fm 5 zl 2 zs 2) for Jettaradio0002.png
    [...]

If the above isn't completely clear, 'pngcrush' examined the first file,
then overwrote the second with an optimized compression of the first.
Result: two files with different names and the same image data, while the
original second file's image data was deleted.

It would be better if 'pngcrush', when commanded to overwrite a file,
did either of two things:

1) Prompt the user: "are you sure you want to erase fubar.png?"

2) Quit, with an error message: "warning output file exists",
   and a "--force" switch could override that.

[Zack Weinberg]

Addendum: In further discussion, A. Costa also points out that the quoted bits of pngcrush output, "Recompressing <name>.png" and "Best method ... for <name2>.png" are both misleading when files will not be overwritten in place. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411032 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411034 .

[Glenn Randers-Pehrson]

It's not unusual for commands to overwrite the destination file if it already exists, e.g., "cp a b" will wipe out an existing "b" with a copy of "a" without a confirmation. Requiring a confirmation would be unusual.

[Zack Weinberg]

I see where you're coming from, but I think the counterargument that someone is likely to do this by accident by typing pngcrush *.png in a directory containing only two .png files is stronger. (Unfortunately on Unix there's no way for the program to tell whether or not "pngcrush foo.png bar.png" is the result of a glob expansion.) It is much less likely for someone to do that with cp or mv.

[Glenn Randers-Pehrson]

Changing the "Best Method..." and "Recompressing..." messages as suggested,
fix will be in pngcrush-1.7.68.

[Glenn Randers-Pehrson]

Fixed in pngcrush-1.7.70:

ls *.png
logo.png
rose.png

pngcrush *.png
...
Recompressing IDAT chunks in logo.png
Total length of data found in critical chunks = 66234
Critical chunk length, method 1 (ws 15 fm 0 zl 4 zs 0) = 42084
Critical chunk length, method 2 (ws 15 fm 1 zl 4 zs 0) > 42084
Critical chunk length, method 3 (ws 15 fm 5 zl 4 zs 1) > 42084
Critical chunk length, method 4 (ws 15 fm 0 zl 9 zs 1) = 37549
Critical chunk length, method 7 (ws 15 fm 0 zl 9 zs 0) = 36617
Best pngcrush method = 7 (ws 15 fm 0 zl 9 zs 0) = 36617
for output to rose.png
(44.72% critical chunk reduction)
(44.72% filesize reduction)