- 2017.05.22 13:25 "Re: [Tiff] Libtiff 4.0.8 released", by PSIRT
-
2017.05.24 18:38 "Re: [Tiff] Sporadic crash on Windows when appending images to TIFF file", by Dinesh Iyer
- 2017.05.24 15:42 "[Tiff] Sporadic crash on Windows when appending images to TIFF file", by Dinesh Iyer
- 2017.05.24 19:19 "Re: [Tiff] Sporadic crash on Windows when appending images to TIFF file", by Bob Friesenhahn
-
2017.07.04 11:04 "[Tiff] A bug in libtiff error/warning handling", by Paavo Helde
-
2017.07.04 11:30 "Re: [Tiff] A bug in libtiff error/warning handling", by Even Rouault
- 2017.07.04 12:20 "Re: [Tiff] A bug in libtiff error/warning handling", by
-
2017.07.04 12:30 "Re: [Tiff] A bug in libtiff error/warning handling", by Paavo Helde
-
2017.07.04 18:38 "Re: [Tiff] A bug in libtiff error/warning handling", by Bob Friesenhahn
- 2017.07.04 19:31 "Re: [Tiff] A bug in libtiff error/warning handling", by Paavo Helde
- 2017.07.05 12:12 "Re: [Tiff] A bug in libtiff error/warning handling", by Edward Lam
-
2017.07.04 18:38 "Re: [Tiff] A bug in libtiff error/warning handling", by Bob Friesenhahn
-
2017.07.04 11:30 "Re: [Tiff] A bug in libtiff error/warning handling", by Even Rouault
2017.05.26 17:42 "Re: [Tiff] Sporadic crash on Windows when appending images to TIFF file", by Dinesh Iyer
Thanks Bob. I will give this a shot as part of upgrading to 4.0.8
On Fri, May 26, 2017 at 11:42 AM, Bob Friesenhahn < bfriesen@simple.dallas.tx.us> wrote:
which is generated when the call to CreateFileW in tif_win32.c fails? Again this failure happens sporadically.
I added a guard in my code to retry opening the file if an error occurs with a pause 0.1 seconds between retries (max 5 retries) and the errors seemed to have gone away.
This might be a Windows file handling issue.
There are two possible I/O implementations available under Windows. The implementations are tif_win32.c and tif_unix.c in the libtiff subdirectory. Either of these may be used and you can switch your build to use tif_unix.c rather than tif_win32.c.
There is a known issue with tif_win32.c in that libtiff only preserves the lower 32-bits (or maybe 31 bits) of the Windows file handle so if the handle requires more bits, then there would be a failure.
In recent libtiff 4.0.X I would expect tif_unix.c to function as well as tif_win32.c, and in some cases better. I am not sure if unicode filenames are supported with tif_unix.c though.