[GRASS-dev] Re: what if: a new GRASS directory layout?

[Ivan Shmakov]

>>>>> Ivan Shmakov <ivan at theory.asu.ru> writes:
>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>> It seems that the reasonable behaviour would be to make a
 >>> back-reference if possible, and issue a warning if not.

 >> A warning isn't sufficent. If the GC relies upon back-references,
 >> but you can't create one, the data could disappear while a process
 >> is trying to use it.

 > Still it's an improvement, since currently the data could just as
 > well be overwritten.  The transition to tmp/ + rename () alone
 > doesn't help much, as a support file may be renamed while the other
 > is being read.

	Thinking on it further, the change to the
	LOCATION/MAPSET/raster/RASTER/ scheme doesn't actually improve
	the situation, as the directory may be renamed while the other
	party reads the support files; e. g., reading the raster `foo':

    raster/foo/bar (old) is read;
    [raster/foo/ is replaced with a newer version;]
    raster/foo/baz (new) is read.

[...]

 >> Essentially, if you can't ensure that the back-references can be
 >> created, you can't design a GC which relies upon them.

 > Well, yes.  That's why I've suggested some solutions in my previous
 > post.  To simplify, they are:

 > * hardlink the entire maps into a place where you can create
 > back-references, e. g. the current mapset;

 > Pro's: could be done with `g.copy' (changed); becomes possible as
 > soon as both the ``in place'' and ``atomic replace'' issues have
 > been dealt with, no need for an inventory scheme;

	Actually no, as long as the raster might be replaced while
	`g.copy' is being run.  And since the other mapset is read-only,
	there's no way to prevent it.

	It thus seems that among the RASTER/ and the inventory scheme,
	only the latter provides good support for concurrency, and not
	the former.

[...]