<div dir="ltr"><div>Hi Even,</div><div><br></div><div>Thanks for your quick response!</div><div><br></div>The issue is not that we are dealing with POSIX TAR files (which actually seems to be handled fine with GDAL 3.1, when we created them using `tar --format=pax`). <div><br></div><div>The issue seems to be the handling of the file user/group separator. Looking at the code, the expected separator is nul (`\0`) (<a href="https://github.com/OSGeo/gdal/blob/master/gdal/port/cpl_vsil_tar.cpp#L336" target="_blank">https://github.com/OSGeo/gdal/blob/master/gdal/port/cpl_vsil_tar.cpp#L336</a>) but our file seems to use space characters as  separators:</div><div><br></div><div>$ python<br></div><div>>>> a = open('a.tar', 'rb').read(1024)</div><div>>>> a[100:150]<br>b'0100644 0000000 0000000 00000000162 13460560104 01'<br></div><div><br></div><div>We believe that this is the relevant line in the specification: <a href="https://github.com/Keruspe/tar-parser.rs/blob/master/tar.specs#L202" target="_blank">https://github.com/Keruspe/tar-parser.rs/blob/master/tar.specs#L202</a>, as it states that both spaces and nuls shall be allowed in the separation of the groups.</div><div><br></div><div>We actually succeeded in loading the tiff when we started the `gdalinfo` with `gdb`, setting a breakpoint in the above location and the did the following for each file:</div><div><br></div><div>(gdb) set abyHeader[115]=0<br>(gdb) set abyHeader[123]=0<br>(gdb) set abyHeader[107]=0<br></div><div><br></div><div>This produced a list of files within that archive.</div><div><br></div><div>So I think, the (already hefty) `if` clause could just be expanded to also allow spaces in the separators and we would be fine.</div><div><br></div><div>Do you think that is feasible?</div><div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 21 Aug 2019 at 13:24, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.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">Fabian,<br>
<br>
/vsitar/ has indeed no dedicated support for POSIX.1-2001 (pax)<br>
<br>
On a very simple test with a tiny file from GDAL autotest,<br>
<br>
tar --format=pax --create -f byte_pax.tar byte.tif<br>
<br>
then gdalinfo /vsitar/byte_pax.tar/byte.tif works.<br>
<br>
But I see that GDAL sees an extra text file "PaxHeaders.25680/byte.tif" which <br>
is the one mentionned in<br>
<a href="https://en.wikipedia.org/wiki/Tar_(computing)#POSIX.1-2001/pax" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Tar_(computing)#POSIX.1-2001/pax</a> which contains <br>
3 timestamps with nanosecond precision.<br>
<br>
So I suspect your particular .tar file uses specific pax extensions which are <br>
not UStar compatible. I didn't dig more. Would probably require an example to <br>
better see what's going on.<br>
<br>
Even<br>
<br>
> Hi list,<br>
> <br>
> We have a large archive of images which are stored in POSIX TAR format<br>
> (POSIX.1-2001 (pax)). GDAL seems to be unable to open these files (GDAL<br>
> 2.4.0). Unfortunately, re-packing these files in GNU format (which GDAL<br>
> seems to be happy with) is not an option.<br>
> <br>
> We also tried with the latest Docker image (alpine-small-latest, GDAL<br>
> 3.1.0dev-3c44aef0f367d0439d42f5384896fc7899317f06), but the same issue<br>
> persists: the GNU tar is opened without issues, the POSIX one fails.<br>
> <br>
> Is it confirmed that GDAL does not have support for that TAR POSIX format?<br>
> How much effort would it be to add support for that format?<br>
> <br>
> Regards,<br>
> Fabian<br>
<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>