[gdal-dev] What is readlink used for?

Kurt Schwehr schwehr at gmail.com
Mon Jan 6 10:35:47 PST 2014

Hi all,

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.
 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?

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.


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/
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/
      different from user name `my_remote_poly.shp'.
1: poly (3D Polygon)

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?

Any thoughts would be appreciated!

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

More information about the gdal-dev mailing list