[gdal-dev] VSIGetMemFileBuffer Returns NULL When Copying Vector Dataset to Vsimem

Soren Saville Scott soren at girraphic.com
Tue Oct 3 21:26:06 PDT 2023


Hi,

I'm integrating GDAL in C++ with a system that defines its own asset types
stored on disk, and am writing a wrapper for datasets using this asset
system. To 'import' a dataset I call GDALOpenEx on it, CreateCopy() it to
some "/vsimem/foo.shp" path, GDALClose() the datasets to flush it, and call
VSIGetMemFileBuffer with bUnlinkAndSeize=true to take ownership of the
underlying memory buffer.

GDALDataset* Dataset = GDALOpenEx("foo.shp", GDAL_OF_VECTOR |
GDAL_OF_VERBOSE_ERROR, nullptr, nullptr, nullptr);
GDALDataset* Copy = Dataset->GetDriver()->CreateCopy("/vsimem/foo.shp",
Dataset, false, nullptr, nullptr, nullptr); //appears to produce a valid
Dataset containing the same layers & features as its source.
GDALClose(Dataset);
GDALClose(Copy);
size_t DataLength;
GByte* Buffer = VSIGetMemFileBuffer("/vsimem/foo.shp", &DataLength, true);
//<-- returns NULL

For some reason VSIGetMemFileBuffer always fails, returning a nullptr. This
is basically identical to a similar problem I had, described here:
 https://stackoverflow.com/questions/73644157/get-raw-buffer-for-in-memory-dataset-in-gdal-c-api
<https://stackoverflow.com/questions/73644157/get-raw-buffer-for-in-memory-dataset-in-gdal-c-api>
which
I never really found a solution to. I have similar issues with other VSI
functions, e.g. calling GDALOpenEx on a path created by
VSIFileFromMemBuffer also fails.

Any idea as to what the problem is here?

Alternatively, maybe there's a better way to 'emplace' datasets inside some
other file?

Thanks,
Soren Saville Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231004/831f556e/attachment.htm>


More information about the gdal-dev mailing list