[Gdal-dev] Problem of creation with Gtiff driver on Solaris

Frédéric Trastour support at geoimage.fr
Mon Sep 12 05:19:51 EDT 2005


Hello Franck,

>>
>>Try the patch (adding TIFFSeekFile(tif,0,SEEK_SET) before the
>>WriteOK call and see if that helps.
>>

Thanks a lot, this solves the problem.

It's really strange anyway and It's not very reassuring to see that simple file
access may be broken on Solaris. There are probably tons of similar code
in other drivers...

>>
>>It was recently removed as there seemed to be no sensible reason
>>for it, and we though that modern Solaris surely would not still
>>have such a problem (assuming I had diagnosed it correctly in the
>>first place).  I am now suspecting that was a mistake.
>>

I think the problem is not solved on Solaris 10 as a user has posted a similar
mail to GDAL list on 1st september.

Perhaps you may consider to reinsert this patch into libtiff for next releases.

Thanks again,

Frédéric.
_________________________________________________________________
Frédéric Trastour - GEOIMAGE - dev at geoimage.fr
----- Original Message ----- 
From: "Frank Warmerdam" <fwarmerdam at gmail.com>
To: "Frédéric Trastour" <support at geoimage.fr>
Cc: <gdal-dev at lists.maptools.org>; "TIFF" <tiff at lists.maptools.org>
Sent: Thursday, September 08, 2005 7:24 PM
Subject: Re: [Gdal-dev] Problem of creation with Gtiff driver on Solaris


On 9/8/05, Frédéric Trastour <support at geoimage.fr> wrote:
> Hello,
>
> I am trying to find why GDAL 1.3.0 with the internal libtiff on Solaris
doesn't
> create valid GEOtiff.
>

Frédéric,

Several years ago I applied the following patch to libtiff's tif_open.c.
It was recently removed as there seemed to be no sensible reason
for it, and we though that modern Solaris surely would not still
have such a problem (assuming I had diagnosed it correctly in the
first place).  I am now suspecting that was a mistake.

Try the patch (adding TIFFSeekFile(tif,0,SEEK_SET) before the
WriteOK call and see if that helps.

warmerda at gdal2200[108]% cvs diff -r1.5 -r1.6 tif_open.c
Index: tif_open.c
===================================================================
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_open.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- tif_open.c  30 Sep 2000 04:18:55 -0000      1.5
+++ tif_open.c  20 Jul 2001 02:22:46 -0000      1.6
@@ -1,4 +1,4 @@
-/* $Header: /cvs/maptools/cvsroot/libtiff/libtiff/tif_open.c,v 1.5
2000/09/30 04:18:55 warmerda Exp $ */
+/* $Header: /cvs/maptools/cvsroot/libtiff/libtiff/tif_open.c,v 1.6
2001/07/20 02:22:46 warmerda Exp $ */

 /*
  * Copyright (c) 1988-1997 Sam Leffler
@@ -285,6 +285,15 @@
                if (tif->tif_flags & TIFF_SWAB)
                        TIFFSwabShort(&tif->tif_header.tiff_version);
                tif->tif_header.tiff_diroff = 0;        /* filled in later */
+
+                /*
+                 * This seek shouldn't be necessary, but I have had some
+                 * crazy problems with a failed fseek() on Solaris leaving
+                 * the current file pointer out of whack when an fwrite()
+                 * is done.
+                 */
+                TIFFSeekFile( tif, 0, SEEK_SET );
+
                if (!WriteOK(tif, &tif->tif_header, sizeof (TIFFHeader))) {
                        TIFFError(name, "Error writing TIFF header");
                        goto bad;




> Here is a trace (some printfs added in tif_vsi.c) of a gdal_translate
execution:
>
> GDAL/GEO: GEODataset::Open :im1x1.geo
> GDAL: GDALOpen(im1x1.geo) succeeds as GEO.
> Input file size is 1, 1
> 0.TIFFOpen FILENAME=im11.TIF, MODE=w+b --> FILE=fe437c64
> tiffReadProc FILE=fe437c64, BUF=2d000, SIZE=8 -->0 [POS=0]
> ** tiffWriteProc FILE=fe437c64, BUF=2d000, SIZE=8 -->8 [POS=-8184] // A 'tell'
> just after the write returns -8184 instead of 8 !
> 100 - done.
> ** tiffSeekProc FILE=fe437c64, OFFSET=0, WHENCE=SEEK_END --> 0 // 0 instead of
8
> tiffWriteProc FILE=fe437c64, BUF=4af00, SIZE=1 -->1 [POS=1]
> tiffSeekProc FILE=fe437c64, OFFSET=0, WHENCE=SEEK_END --> 1
> tiffSeekProc FILE=fe437c64, OFFSET=4, WHENCE=SEEK_SET --> 4
> tiffWriteProc FILE=fe437c64, BUF=ffb8dc5c, SIZE=4 -->4 [POS=8]
> tiffSeekProc FILE=fe437c64, OFFSET=164, WHENCE=SEEK_SET --> 164
> tiffSeekProc FILE=fe437c64, OFFSET=164, WHENCE=SEEK_SET --> 164
> tiffWriteProc FILE=fe437c64, BUF=2f110, SIZE=128 -->128 [POS=292]
> tiffSeekProc FILE=fe437c64, OFFSET=2, WHENCE=SEEK_SET --> 2
> tiffWriteProc FILE=fe437c64, BUF=ffb8dcd6, SIZE=2 -->2 [POS=4]
> tiffWriteProc FILE=fe437c64, BUF=4af00, SIZE=156 -->156 [POS=160]
> tiffWriteProc FILE=fe437c64, BUF=ffb8dcd0, SIZE=4 -->4 [POS=164]
> tiffCloseProc FILE=fe437c64
>
> ERROR 4: `im11.TIF' not recognised as a supported file format.
> ERROR 4: `im11.TIF' not recognised as a supported file format.
>
> GDAL: GDALDeregister_GTiff() called.
>
> As you can see there are two strange results (marked with **).
> Any ideas about that ?
>
> Does it work on any other unix platforms ?
>
> Thanks
> Frédéric.
> _________________________________________________________________
> Frédéric Trastour - SpacEyes - dev at spaceyes.fr
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
>


-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent




More information about the Gdal-dev mailing list