[gdal-dev] Re: TiffAppendToStrip errors with uncompressed output [SOLVED]

[Even Rouault]

Le mercredi 09 mai 2012 12:13:06, Jukka Rahkonen a écrit :
> Ahem,
> 
> It seems to be so that compression makes resulting tiff files smaller.  In
> some cases they can then fit to almost full disk even there is not enough
> room for an uncompressed version.
> 
> An explanation for why I did not notice that disk was too full was that the
> LZW compression is so effective for this dataset. The difference is as big
> as 272 MB with LZW compression and 4500 MB as uncompressed. The tiff
> driver error message is not most obvious either
> TIFFAppendToStrip:Write error at scanline 14650
> 
> The error message from HFA driver was pretty easy to interpret:
> ERROR3: Failed to extend imgtest.ige to full size
> likely out of disk space.
> No space left on device.
> 
> This makes me think about two improvements:
> - Make GTiff driver to give better understandable error message when disk
>  gets full

I've added into trunk a better error reporting that will output the reason for 
the failure similarly to the HFA driver.

For example :

0...10...20...30...40...50...60...70...80...90...100 - done.
ERROR 1: _tiffWriteProc:No space left on device
ERROR 1: TIFFAppendToStrip:Write error at scanline 272
[...]

> - In case of uncompressed tiff output, make driver to test beforehand if
> there is enough disk space for the target image

I'm not aware of a portable way of doing that (I haven't searched a lot 
though). For the record, I've tried the following trick : seek to the offset 
that should be the end of the uncompressed file and write a byte. But on Linux, 
due to the way the file system works, this does not work as expected, because 
'skipped' sectors are not allocated at all, so it just needs the size for one 
byte (actually a sector I guess), and not the full file size... We could write 
0's to the file, but that would defeat the purpose of a quick check.

> 
> I would guess that sometimes the latter could prevent some frustration
> caused by a many hours conversion job going in vain because of running out
> of disk space.
> 
> -Jukka Rahkonen-
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev