2005.12.11 12:44 "[Tiff] [PATCH] LynxOS compile fixes", by Olli Savia

2005.12.14 02:34 "RE: [Tiff] Bug in tiffcp (unsupported codecs return 0)", by Jason Frank

As a compromise, perhaps a command line option could be added which turns on

this behaviour?


I'm not really picky either way. I think that Andrey and I might have gotten crossed up over the 2 modes of tiffcp though. If you specify the -a flag, it should append to the existing image. When I do that with my patch applied, it does not change the existing image, that's exactly what I expect it to do, and I'm quite happy with that. If you don't specify the -a flag, it uses the last file name to create a new image. In this case, we've created the file ourselves. That's the one I'm asking about the unlink on. I don't think Andrey has a problem with that, but I'll let him speak for himself...

There is another issue with Andrey's patch. When I tested it out, it didn't fix my problem. All of his changes appear to be to the readFunc's. The patch I submitted was to oe of the cpFunc's. The test image that I'm using is being handled by the cpDecodedStrips function, which is a cpFunc. So, once I overwrote my change with Andrey's, it stopped working.

Luckily, I don't think this is that bad of a change. I think that all we need to do is to make the same change to cpFuncs that we made to the readFuncs. And, since we're here, do we need to do the same to the writeFuncs (or at least review them?)