[GRASS-dev] r65348 (GRASS_TMPDIR_MAPSET)

[Glynn Clements]

Martin Landa wrote:

> 2015-06-04 16:08 GMT+02:00 Glynn Clements <glynn at gclements.plus.com>:
> 
> > The the temporary files used by lib/raster need to be on the same
> > filesystem as the mapset regardless of any environment settings.
> 
> please could you write us why?

So that they can be rename()d into place.

Copy-and-delete isn't remotely the same thing. Aside from the
gratuitous performance hit, it creates a window where the cell/fcell
file is invalid.

[Technically there's already a window because we remove() the file
first because Windows doesn't support atomic rename(), but that's
minuscule compared to the time taken to copy a file.]

On that note, G_rename() should be called e.g. G_rename_or_copy() or
G_move_file() or something, to avoid misleading anyone. A "rename" has
specific semantics which G_rename() doesn't provide (e.g. preservation
of hard links, permissions, ownership, extended attributes, inode
number, holes, open descriptors, ... everything except the path, in
fact).

> I didn't find any problem (bearing in
> mind changes in G_rename_file() which tries to rename file and if
> fails copy & remove). Anyway, I wonder how to treat raster lib and
> vector lib differently. Martin

I don't know what the vector library's requirements are, but any
temporary file which is intended to be moved to a specific location
should be created such that it can be rename()d to that location (i.e. 
on the same filesytem).

The new behaviour is fine for code which wants a temporary file and
doesn't care where it goes (e.g. because it will never be moved).

But there's no justification for the previous behaviour being removed.

-- 
Glynn Clements <glynn at gclements.plus.com>