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

Even Rouault even.rouault at spatialys.com
Wed Sep 23 13:22:01 PDT 2020


/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 

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)


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200923/86f3b52e/attachment.html>

More information about the gdal-dev mailing list