<div dir="ltr">From what I can tell, the files at <a href="https://www.awaresystems.be/imaging/tiff/bigtiff.html">https://www.awaresystems.be/imaging/tiff/bigtiff.html</a> (see the "Download" link at the bottom) have examples where there are 64-bit offsets past 2GB, for example in the Description entry.<div><br></div><div>For what we want, I think it doesn't make sense to ask file/magic to support 64-bit offsets.  We had been thinking of using libmagic to extract a bunch of metadata (in the way that it outputs width, height, bps, etc for tiff and png) but I think it makes more sense to use the file/magic to identify it as a bigtiff and then hand it to our tiff parser which supports these large offsets.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 13, 2024 at 9:55 AM Christos Zoulas <<a href="mailto:christos@zoulas.com">christos@zoulas.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br id="m_-2978791449728447169lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Mar 26, 2024, at 5:22 PM, David Konerding <<a href="mailto:dakoner@gmail.com" target="_blank">dakoner@gmail.com</a>> wrote:</div><br><div><p><u></u>Hi,<u></u></p><p><u></u>I am trying to write a rule to extract more info from BigTIFF.  Currently, TIFF files extract directory entries and output metadata, while BigTIFF only reports the file type and endian.<br><br>Working from this page, <a href="http://bigtiff.org/" target="_blank">http://bigtiff.org/</a> I am trying to read the offset to the first directory entry; in TIFF, this is a short (16-bit), while in BigTIFF, it's a quad (64-bit) to support files with very large offsets.<u></u></p><u></u><p><u></u><br><u></u></p><u></u><p><u></u>As such, I am trying to write this continuation:<u></u></p><u></u><p><u></u>>>>(8.Q) use            \^bigtiff_ifd<br><u></u></p><u></u><p><u></u>Which IIUC is saying "starting at file offset 8, read a bequad (64 bit) and then recursively call the named magic bigtiff_ifd (which is slightly different from tiff_ifd).<u></u></p><u></u><p><u></u><br><u></u></p><u></u><p><u></u>When I try this on my test file (a big-endian BigTIFF), I get this debug error:<u></u></p><u></u><p><u></u><u></u></p><u></u><p><u></u>10: >>>> 8(bequad,&0), use,='^bigtiff_ifd',""]<br>lhs/off overflow 28956860354 0<br><u></u></p><u></u><p><u></u><br><u></u></p><u></u><p><u></u>If I understand the code in do_ops correctly (<a href="https://github.com/file/file/blob/master/src/softmagic.c#L1465" target="_blank">https://github.com/file/file/blob/master/src/softmagic.c#L1465</a>) <u></u></p><u></u><p><u></u>the values for lhs and off are compared to UINT_MAX and INT_MIN, and a failure is reported if the value is too large.<u></u></p><u></u><p><u></u>On my 64-bit system, UINT_MAX seems to be based on 32-bit integer, which causes the overflow error when compared against a 64-bit value.<u></u></p><u></u><p><u></u><br><u></u></p><u></u><p><u></u>Before I proceed, wanted a sanity check here: are 64-bit offsets larger than 2**32 considered invalid by file?<u></u></p><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u><u></u></div></blockquote>Yes, If you look in <a href="https://github.com/file/file/blob/master/src/file.h#L360" target="_blank">https://github.com/file/file/blob/master/src/file.h#L360</a> offsets are 32 bits right now. </div><div>It would not be too hard to change everything to be 64 bits, but the question is: is it really looking for</div><div>magic data past 2GB and it is correct (the data is there)? So far I have not found the need to change</div><div>the code to support 64 bit offsets...</div><div><br></div><div>christos</div><br></div></blockquote></div>