[gdal-dev] vsipreload: enabling VSI Virtual File API for regular I/O

[Even Rouault]

> I have managed to get it working buy using LD_PRELOAD=./vsipreload.so

Yes for some strange reason, some systems require the ./ and some not... My 
old Ubuntu 10.04 does no, but Travis on Ubuntu 12.04 does. Perhaps some 
security measure that has been added in LD_PRELOAD mechanism.

I've just adjusted the examples in the .cpp header to add ./

> 
> e.g.
> LD_PRELOAD=./vsipreload.so gdalinfo /vsicurl/
> http://download.osgeo.org/gdal/data/netcdf/utm-big-chunks.nc
> 
> It seems that setting LD_PRELOAD outside of the command works also, so this
> mechanism would be used transparently.
> But does it have a significant overhead and/or chances it might do damage
> if always set?

This should have no impact for I/O on regular files, except for a hopefully 
small performance hit to check if the FILE* is a regular one (and redirect to 
the glibc function) or one that is a VSILFILE* instead (and redirect to VSI 
implementation). On /vsiXXXX files, crashes are theoretically possible if a 
glibc function using the fake FILE* is used, but not overloaded in the .so. 

> 
> e.g.
> export LD_PRELOAD=./vsipreload.so
> gdalinfo /vsicurl/
> http://download.osgeo.org/gdal/data/netcdf/utm-big-chunks.nc
> 
> 
> Is there any way this could be integrated into gdal to transparently
> support vsifile for all drivers, without setting LD_PRELOAD?

None that I'm aware of. LD_PRELOAD is really something that must be specified 
before process launching. When GDAL code is reached, it is too late (and those 
limitations are really welcome for obvious security reasons).

> In this way this feature would be available to all gdal commands or even
> other apps that use gdal.
> 
> For example, /vsizip/ is used in QGIS, but it does not work with certain
> files (e.g. netcdf ) inside archives. But if I use LD_PRELOAD it works for
> netcdf files! Neat stuff!
> e.g. LD_PRELOAD=./vsipreload.so qgis

As I mentioned in another post in that thread, the use of a fuse filesystem 
could make it less hackish, although you would need permissions to mount on 
/vsizip , /vsicurl etc which might be problematic if you are not a good friend 
with the system administrator. You don't need to be root to mount a fuse 
filesystem, but you must have write permissions on the mount point I believe.

> 
> great work
> Etienne

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html