[gdal-dev] About the interaction between VRT and VSIMEM

[Even Rouault]

Sean,

/vsimem/ tries to honour POSIX file behaviour. That is you can delete a file while it has file 
descriptors opened on it, and the file will actually be destroyed when the last file descriptor 
is closed, but nobody is able to open/list it in the meantime. (by the way, I wouldn't be 
surprised that /vsimem/ would have issues if you recreated a file with the same name. not 
sure what POSIX says about that. but that's not related to your scenario)

In your scenario, the C++ object corresponding to rgb has a VSILFILE* opened on it. And the C
++ object corresponding to vrt keeps the C++ object corresponding to rgb alive, hence this 
works.

Note that this behaviour might not be necessarily be found if using non-warped VRTs, that 
generally do not open the sources until they are really needed (to avoid opening too many 
files at once)

Even

> Hi all,
> 
> I've written a test for rasterio and the output has me scratching my head.
> The gist of it: It creates a VSIMEM file copied from an ordinary GeoTIFF on
> my filesystem, calls GDALOpenEx on the VSIMEM file to get a handle, calls
> GDALAutoCreateWarpedVRT with that handle to make a warped VRT and then it
> deletes the VSIMEM dataset. In Python it looks like
> 
> with open("RGB.byte.tif", "rb") as fp:
>     data = fp.read()
> 
> with MemoryFile(data) as memfile:  # copies the bytes to a
> /vsimem/foo/bar.tif file, the exact name isn't important.
> 
>     with memfile.open() as rgb:
>         vrt = WarpedVRT(rgb, dst_crs="EPSG:3857")  # there are two
> GDALDatasetH in the program now, one on /vsimem/foo/bar.tif and one on the
> in-memory warped VRT that references the /vsimem file.
> 
> 
>     # At this point /vsimem/foo/bar.tif is closed.
> 
> # At this point /vsimem/foo/bar.tif is deleted. I've confirmed by calling
> VSIReadDirRecursive().
> 
> arr = vrt.read()
> 
>            # Surprise!
> 
> I'm able to read data from the warped VRT after the VSIMEM file it
> references has been deleted. I'm not sure how to interpret this. Was the
> raster data of /vsimem/foo/bar.tif cached somewhere? Did the GeoTIFF driver
> not actually delete the VSIMEM file?


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200923/86f3b52e/attachment.html>