Martin Landa wrote:
2015-06-04 16:08 GMT+02:00 Glynn Clements gl...@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
Martin Landa wrote:
Yes. I'd prefer that lib/raster continues to create the file on the
same filesystem as the mapset and atomically rename()s it into place.
IOW, the new tempfile behaviour needs to be availble in addition to
the long-standing behaviour, not a replacement for it.
Hi,
2015-06-04 16:08 GMT+02:00 Glynn Clements gl...@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? I didn't find any problem (bearing in
mind changes in
On Wed, Jun 3, 2015 at 9:55 AM, Glynn Clements gl...@gclements.plus.com
wrote:
Maybe I'm overlooking something, but this change appears to violate
the requirement that the file created by G_tempfile() is on the same
filesystem (partition) as the mapset directory.
Certain files (e.g. the
Hi,
2015-06-03 15:55 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
Maybe I'm overlooking something, but this change appears to violate
the requirement that the file created by G_tempfile() is on the same
filesystem (partition) as the mapset directory.
right, see [1,2].
Certain files
Martin Landa wrote:
I have updated G_rename_file() to deal with it [3], do you prefer
another solution?
Yes. I'd prefer that lib/raster continues to create the file on the
same filesystem as the mapset and atomically rename()s it into place.
IOW, the new tempfile behaviour needs to be
Hi,
2015-06-03 20:12 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
Yes. I'd prefer that lib/raster continues to create the file on the
same filesystem as the mapset and atomically rename()s it into place.
IOW, the new tempfile behaviour needs to be availble in addition to
the
