Opened 19 years ago
Closed 13 years ago
#704 closed defect (invalid)
DIR and SUBDIR appending with libtiff and GDAL's libtiff
Reported by: | Owned by: | dron | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | GDAL |
Cc: |
Description (last modified by )
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)
Change History (9)
by , 19 years ago
Attachment: | tiff_append.c added |
---|
comment:1 by , 19 years ago
Julien, The last problem (with the subdirectory creation) should be fixed now (see Bug #703 for details). Andrey
comment:2 by , 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 , 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 , 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 , 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 , 13 years ago
Description: | modified (diff) |
---|---|
Resolution: | → invalid |
Status: | reopened → closed |
Not obvious it is a GDAL problem. Closing
Note:
See TracTickets
for help on using tickets.
tiff_append.c