2020.08.06 19:43 "Re: [Tiff] Unable to read a large TIFF File (single image, one IFD, Strip image of size 2.6 GB) on Unix using TIFFClientOpen API", by Bob Friesenhahn

In Linux, the progression of bytes read is different after a certain point compared to Windows and then fails with error ; 'TIFFFillStrip: Read error at scanline 4294967295; got 2263871488 bytes, expected 2637881541.'

bytes_read = 8
bytes_read = 2
bytes_read = 192
bytes_read = 4
bytes_read = 6
bytes_read = 16
bytes_read = 48
bytes_read = 1048576
bytes_read = 10485760
bytes_read = 104857600
bytes_read = 2147479552

'TIFFFillStrip: Read error at scanline 4294967295; got 2263871488 bytes, expected 2637881541.'

The part in yellow is bizarre and different than Windows. File size is 2637881818 (~2.6 GB). Also, we noticed that the callback to get size of the file (TIFFSizeProc) is invoked in Windows for large files like this one but not in Unix (not sure if this was an intentional implementation). Can you reproduce this for a similar sized single strip TIFF image in Linux? Our code is same in Windows and Unix.

I am color-blind today. You need to take care that your file I/O routines can handle the size requested. If it can handle only smaller amounts at a time, then multiple I/Os may be required.

Take care about the data type that you used to store the size value. for example, a signed 32-bit integer can handle only a maximum value of 2147483647 before undefined behavior will occur. If there is any overflow during calculations, it might result in a request for a different amount than expected.

Under Linux, the off_t type might be a 32-bit or 64-bit signed type.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt