[GRASS-dev] No longer able to open a mapset by symbolic link

Glynn Clements glynn at gclements.plus.com
Tue Apr 3 05:34:45 EDT 2007

Markus Neteler wrote:

> >> I just retrieved the latest weekly CVS snapshot for GRASS and found
> >> I'm no longer able to access mapsets that are referred to by symbolic
> >> links in linux.
> >>
> >> Is this intended behaviour (possibly related to the windows port)? Or a bug?
> >> ...
> > AFAIK, having symlinks to mapset directories has never been
> > intentionally supported; it just happened to work.
> I am long term user of such mapset links, it would be a major problem for us
> to no longer have this possibility. Just to express interest in this
> issue...

In that case, we need to add a G_stat(), and change some uses of
G_lstat() to G_stat().

Current users of G_lstat() are:

	recursive_copy(), used by do_copy(), used by g.copy

	G__mapset_permissions(), G__mapset_permissions2()

	recursive_remove(), used by G_remove()

	_get_make_sock_path(), used by G_sock_get_fname()

	_make_toplevel(), _make_sublevels(), both used by G_rc_path()

AFAICT, the problems are due to G__mapset_permissions() and/or
G__mapset_permissions2(). These can probably be safely changed to use
stat() instead.

recursive_copy() and recursive_remove() perform directory traversal,
which should only recurse into actual subdirectories, not symlinks to

The other cases check whether a directory already exists prior to
creating it. It's debatable what they should do if the chosen
subdirectory name refers to an existing symlink.

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list