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

[Glynn Clements]

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:

general/manage/lib/do_copy.c
	recursive_copy(), used by do_copy(), used by g.copy

lib/gis/mapset_msc.c
	G__mapset_permissions(), G__mapset_permissions2()

lib/gis/remove.c
	recursive_remove(), used by G_remove()

lib/gis/unix_socks.c
	_get_make_sock_path(), used by G_sock_get_fname()

lib/gis/user_config.c
	_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
directories

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>