[gdal-dev] What is readlink used for?

[Kurt Schwehr]

Thanks for pointing me right at the vrt readlink changeset.

This re-arrangement of files is done without me or gdal doing anything.

# readonly filesystem with data used by tests.  Note that the checksums are
different directories
/data/checksum1/a.vrt
/data/checksum2/small.raw

# each test gets it's own working area
/ramdrive/test1234/a.vrt -> /data/checksum1/a.vrt
/ramdrive/test1234/small.raw -> /data/checksum2/small.raw

The test is then given /ramdrive/test1234/a.vrt

As for the config options, I was trying to think out loud if a config
option needed to be added to allow switching of readlink behavior in
vrtdataset.cpp.


On Mon, Jan 6, 2014 at 10:56 AM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> Hi Kurt,
>
> >
> > I ran into trouble with readlink as can be seen in
> > http://trac.osgeo.org/gdal/ticket/5340.  I'm working with a system where
> > the run directory is all symbolic links.  So if I have nonsquare.vrt
> > refering to "./small.raw", readlink of nonsquare.vrt will end up being
> in a
> > totally different directory than the small.raw file.
> >
> > So... That begs the question of the purpose of dereferencing symbolic
> links
> > using readlink (e.g.
> >
> http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/vrt/vrtdataset.cpp#L687
> > ). Is this done just for performance on filesystems where symbolic links
> > might be a performance hit (e.g. nfs file systems over slow networks and
> > an OS that does not do a good job caching)?  Or is there something else
> > important that I'm missing?
>
> This was added in http://trac.osgeo.org/gdal/changeset/25682 . The
> autotests
> added in that commit show the use cases that are solved. They seem to be
> rather reasonable.
>
> I'm having trouble to understand your use case that doesn't work. Perhaps
> you
> could explain it in a more "graphical" way ( "ls -al" in the relevant
> directories will do )
>
> >
> > I see 4 places where readlink is used:
> >
> > ./ogr/ogrsf_frmts/generic/ogrsfdriverregistrar.cpp:        int nBytes =
> > readlink(pszName, szPointerFilename, sizeof(szPointerFilename));
> > ./gcore/gdalopeninfo.cpp:        int nBytes = readlink(pszFilename,
> > szPointerFilename, sizeof(szPointerFilename));
> > ./port/cpl_getexecpath.cpp:    nResultLen = readlink( osExeLink,
> > pszPathBuf, nMaxLength );
> > ./frmts/vrt/vrtdataset.cpp:            int bufferSize =
> > readlink(currentVrtFilename, filenameBuffer, sizeof(filenameBuffer));
> >
> > ogrsfdriverregistar.cpp looks like a possible issue.
> >
> >
> http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/generic/ogrsf
> > driverregistrar.cpp#L250
> >
> > I see that sort of works...
> >
> > ogrinfo my_remote_poly.shp
> > ERROR 4: Unable to open /vsicurl/
> > http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp or /vsicurl/
> > http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.SHP.
> > Had to open data source read-only.
> > INFO: Open of `my_remote_poly.shp'
> >       using driver `ESRI Shapefile' successful.
> > INFO: Internal data source name `/vsicurl/
> > http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp'
> >       different from user name `my_remote_poly.shp'.
> > 1: poly (3D Polygon)
>
> Yes this is convenient to be able to "ln -s /vsicurl/http://somethnig" to
> something.
>
> >
> > I'm thinking that I should just disable readlink entirely.
>  Alternatively,
> > hhould there be a flag that controls readlink just for working with vrt's
> > or a runtime ConfigSetting that could turn on/off readlink?
>
> No there's no such runtime configuration option.
>
> >
> > Any thoughts would be appreciated!
> >
> > Thanks,
> > -kurt
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140106/ffb9a2f3/attachment.html>