Opened 19 years ago

Closed 13 years ago

#704 closed defect (invalid)

DIR and SUBDIR appending with libtiff and GDAL's libtiff

Reported by: dem@… Owned by: dron
Priority: high Milestone:
Component: default Version: unspecified
Severity: normal Keywords: GDAL
Cc:

Description (last modified by Even Rouault)

Andrey,

I've just remade my tests about tiff directory and subdirectory writing and
appending with last CVS libtiff and CVS GDAL's libtiff, and I've still found
these problems :
	- tiff_append.c : write a simple TIFF, close it, reopen it in append mode and
add a simple second directory doesn't work with GDAL's libtiff : output file has
only one directory ;
	- tiff_dir_rw.c : read a directory of a TIFF and add one to it simultaneously :
doesn't work with GDAL's libtiff :
"TIFFReadDirectory: tiff_dir_rw_gdal.tif: Can not read TIFF directory count.
Segmentation fault (core dumped)"
	- tiff_subdir.c : write a subdirectory to a TIFF : doesn't work with the 2
libtiff, standard and GDAL : the subdirectory isn't written.

Note my little test programs are auto sufficient and needn't any data.

Thanks in advance for help,

Julien

Attachments (3)

tiff_append.c (1.2 KB ) - added by dem@… 19 years ago.
tiff_append.c
tiff_dir_rw.c (2.0 KB ) - added by dem@… 19 years ago.
tiff_dir_rw.c
tiff_subdir.c (2.3 KB ) - added by dem@… 19 years ago.
tiff_subdir.c

Download all attachments as: .zip

Change History (9)

by dem@…, 19 years ago

Attachment: tiff_append.c added

tiff_append.c

by dem@…, 19 years ago

Attachment: tiff_dir_rw.c added

tiff_dir_rw.c

by dem@…, 19 years ago

Attachment: tiff_subdir.c added

tiff_subdir.c

comment:1 by dron, 19 years ago

Julien,

The last problem (with the subdirectory creation) should be fixed now (see Bug
#703 for details).

Andrey

comment:2 by dron, 19 years ago

Julien,

It seems that all your test cases work fine with the latest libtiff (from the
CVS). Please, verify it in your environment. I want to release 3.7.1 version
very shortly and afterwards the GDAL code will be sinchronized with the latest
changes, so problems should gone in GDAL too.

Andrey

comment:3 by dem@…, 19 years ago

Andrey,

OK all works fine for libtiff on my environment too.

I've tried overwritten my GDAL's CVS libtiff with the CVS standard libtiff, and
it still doesn't work (at least tiff_append.c) in GDAL.
I believe the remaining problems are only related to libtiff in GDAL.
Maybe it's because things don't work exactly identical in the 2 cases : example
: with my standard libtiff mmap is active, but in GDAL it is always disabled...

Thanks,

Julien

comment:4 by dron, 19 years ago

Well... so I'm reassing this one to GDAL (for further clarification). Probably
we do not have any problems with GDAL's libtiff, but I shall check it once againe.

Andrey

comment:5 by dem@…, 19 years ago

Andrey,

I've done some tests (on Linux), and with the last version there are still
problems I reported but if I replace the GDAL's tif_vsi.c by the libtiff
tif_unix.c, all my 3 test programs works well.

I have investigated and I think the problem is that tif_vsi.c uses fopen,
fclose, fread, ... (by the CPL functions) and tif_unix.c uses open, close, read,
... instead.
In the fopen man, I see :
"`a'
     Open the file for appending data, that is writing from the end of
     file.  When you open a file this way, all data always goes to the
     current end of file; you cannot change this using `fseek'."

and

"Use `"r+"' (or `"rb+"') to permit reading and writing anywhere in an
       existing file, without discarding any data; `"w+"' (or `"wb+"') to cre-
       ate  a  new file (or begin by discarding all data from an old one) that
       permits reading and writing anywhere in it; and `"a+"' (or `"ab+"')  to
       permit  reading  anywhere  in an existing file, but writing only at the
       end."

Maybe this is the cause of the problem ?
I understand that we can't modify the first directory to append a new one in
"a(+)" mode with fopen.
And the tiff_append.c program doesn't give an error, it seems append the
directory (the output file is bigger), but the new directory doesn't seem linked
to the first.
And in my test program tiff_append.c if I replace the "a" by "r+", it works well
(I have also to add a TIFFSetDirectory(tif, 1)), and it is what I understand in
the fopen man.
But change "a" by "r+" doesn't solve the tiff_dir_rw.c and tiff_subdir.c bugs...

In my code I think I'll use a patch to use tif_unix.c instead tif_vsi.c...
Maybe add VSIOpenL (using open and not fopen), VSIClose and other functions to
the CPL library and use them in tif_vsi.c solve all problems.

I've seen that mmap is descativated in tif_vsi.c ; are there reasons for this ?
Isn't it bad for performances ?


Thanks in advance,

Julien

comment:6 by Even Rouault, 13 years ago

Description: modified (diff)
Resolution: invalid
Status: reopenedclosed

Not obvious it is a GDAL problem. Closing

Note: See TracTickets for help on using tickets.