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

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

[...]

 >>> In the case of multiple concurrent writes, you're bound to lose one
 >>> of the two writes whichever mechanism is used.

 >> I don't understand how the schemes being discussed are different
 >> with respect to this point?

 > They aren't.

 > The only way that this issue can be prevented is if each module is
 > treated as a single transaction. In practice, it shouldn't be that
 > much of a problem; if two processes are trying to replace the same
 > map with competing versions, that's really an organisational issue,
 > not a technical issue.

	Agreed.

[...]

 >> From the discussion, I could conclude that the inventory scheme
 >> doesn't necessary imply any better concurrency (other than by
 >> allowing certain ways of lock-less access), nor does it prevent the
 >> concurrency to be improved (by means of the OS locking.)

 >> Still, I believe the inventory scheme to be more flexible and to
 >> allow for both cleaner and extensible API, and a cleaner
 >> implementation.

	... And it eliminates certain problems with database replication
	as well.

 > The main disadvantage is it makes it harder for the user to analyse
 > or modify the database manually (which is sometimes necessary).

	The use of advisory locks seem to make manual modifications
	harder as well.  May I suggest g.replacefile and (or) g.editfile
	to complement g.findfile, ensuring proper locking is done?

	BTW, it would be nice to have a way to obtain a list of all the
	files comprising the given raster or rasters.