Quantcast

[gdal-dev] Symlinks to VRTs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] Symlinks to VRTs

Luis Ressel
Hello,

VRTs can reference other files by relative paths. Upon reading such a
VRT, GDAL will evaluate the relative path based on the directory where
the VRT resides. Now, imagine the following situation:

* There's a directory a/ containing several raster files and a VRT
  referencing them.

* There's a second directory b/ containing a symlink to the VRT in a/ .

When I point GDAL at b/symlink.vrt, it will dereference the symlink
before evaluating the relative paths inside the VRT (and thus search
for the rasters in a/), whereas I would've expected GDAL to handle
the symlink transparently and search for the rasters in b/ .

Is this the intended behaviour? Unfortunately, I can't make much
sense of the relevant code in gdal/frmts/vrt/vrtsources.cpp.

Regards,
Luis Ressel

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Symlinks to VRTs

Even Rouault-2

On mercredi 8 mars 2017 19:38:24 CET Luis Ressel wrote:

> Hello,

>

> VRTs can reference other files by relative paths. Upon reading such a

> VRT, GDAL will evaluate the relative path based on the directory where

> the VRT resides. Now, imagine the following situation:

>

> * There's a directory a/ containing several raster files and a VRT

> referencing them.

>

> * There's a second directory b/ containing a symlink to the VRT in a/ .

>

> When I point GDAL at b/symlink.vrt, it will dereference the symlink

> before evaluating the relative paths inside the VRT (and thus search

> for the rasters in a/), whereas I would've expected GDAL to handle

> the symlink transparently and search for the rasters in b/ .

>

> Is this the intended behaviour?

 

Given that the existing behaviour is a reasonable one, I'd say yes. That's said your use can can probably also makes sense.

 

 

> Unfortunately, I can't make much

> sense of the relevant code in gdal/frmts/vrt/vrtsources.cpp.

 

The relevant piece of code is in

https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L739

 

If you look a bit below in

https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L814

there's an open option ROOT_PATH that could be set to b/ to get the behaviour you wish.

 

Or you could add an open option, RESOLVE_SYMLINK=NO, to disable the stuff at

https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L745

 

Evn

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Symlinks to VRTs

Luis Ressel
On Wed, 08 Mar 2017 21:28:34 +0100
Even Rouault <[hidden email]> wrote:

> The relevant piece of code is in
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L739
>
> If you look a bit below in
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L814
> there's an open option ROOT_PATH that could be set to b/ to get the
> behaviour you wish.

Thanks for the hint! Adjusting the ROOT_PATH is an acceptable solution
in my use case.

Interestingly, GDAL used to handle symlinks to VRTs in the way I'd
expected, but this was changed back in 2013 (commit 66b3918df in the
git repository, committed by you).

Regards,
Luis Ressel

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Symlinks to VRTs

Even Rouault-2

On mercredi 8 mars 2017 22:37:42 CET Luis Ressel wrote:

> On Wed, 08 Mar 2017 21:28:34 +0100

>

> Even Rouault <[hidden email]> wrote:

> > The relevant piece of code is in

> > https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L73

> > 9

> >

> > If you look a bit below in

> > https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L81

> > 4

> > there's an open option ROOT_PATH that could be set to b/ to get the

> > behaviour you wish.

>

> Thanks for the hint! Adjusting the ROOT_PATH is an acceptable solution

> in my use case.

>

> Interestingly, GDAL used to handle symlinks to VRTs in the way I'd

> expected, but this was changed back in 2013 (commit 66b3918df in the

> git repository, committed by you).

 

Looking at the commit message, it appears that this change was contributed by someone else from https://trac.osgeo.org/gdal/ticket/4999

But my intuition is that the current behaviour is more natural than the previous one (ie the one you'd expect). But obviously different people have different use cases.

 

>

> Regards,

> Luis Ressel

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Symlinks to VRTs

Kurt Schwehr-2
You can also disable readlink to fix some issues.  e.g. in a content addressable storage (CAS) filesystem, every file is typically in a separate directory, so you don't want links dereferenced.

On Wed, Mar 8, 2017 at 1:46 PM, Even Rouault <[hidden email]> wrote:

On mercredi 8 mars 2017 22:37:42 CET Luis Ressel wrote:

> On Wed, 08 Mar 2017 21:28:34 +0100

>

> Even Rouault <[hidden email]> wrote:

> > The relevant piece of code is in

> > https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L73

> > 9

> >

> > If you look a bit below in

> > https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtdataset.cpp#L81

> > 4

> > there's an open option ROOT_PATH that could be set to b/ to get the

> > behaviour you wish.

>

> Thanks for the hint! Adjusting the ROOT_PATH is an acceptable solution

> in my use case.

>

> Interestingly, GDAL used to handle symlinks to VRTs in the way I'd

> expected, but this was changed back in 2013 (commit 66b3918df in the

> git repository, committed by you).

 

Looking at the commit message, it appears that this change was contributed by someone else from https://trac.osgeo.org/gdal/ticket/4999

But my intuition is that the current behaviour is more natural than the previous one (ie the one you'd expect). But obviously different people have different use cases.

 

>

> Regards,

> Luis Ressel

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev



--

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Symlinks to VRTs

Luis Ressel
On Fri, 10 Mar 2017 10:05:13 -0800
Kurt Schwehr <[hidden email]> wrote:

> You can also disable readlink to fix some issues.  e.g. in a content
> addressable storage (CAS) filesystem, every file is typically in a
> separate directory, so you don't want links dereferenced.

Yes, that's exactly my setup (I'm using git-annex for file
archival and synchronization).

> https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_config.h.in#L151

Thanks, that's a neat idea! Disabling HAVE_READLINK will break some
functionality in gcore/gdalopeninfo.cpp, but none that I care about.

Regards,
Luis Ressel

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

attachment0 (849 bytes) Download Attachment
Loading...