On lines 313 and 324 db/drivers/dbf/tables.c contains a call to 'mv'. This
fails under Windows as the command cannot be found.
There is a #ifdef __MINGW32__ between the two calls. If this becomes true,
do we still need the mv calls ?
Moritz
Moritz Lennert wrote:
On lines 313 and 324 db/drivers/dbf/tables.c contains a call to 'mv'. This
fails under Windows as the command cannot be found.There is a #ifdef __MINGW32__ between the two calls. If this becomes true,
do we still need the mv calls ?
IMHO, that code (and the strikingly similar code in close_new() in
lib/gis/closecell.c) is bogus. It should just be using rename().
The link() + remove() idiom may have been to deal with breakage on
NFS, where rename() may not be atomic[1], but link() always is. Given
that you shouldn't be performing multiple concurrent operations in a
single mapset directory[2], I don't see this as an important
consideration.
[1] One of the reasons why NFS is often thought to stand for
"Not a File System", as it violates a number of important Unix
filesystem semantics.
[2] Most GRASS database (gisdbase) operations *aren't* performed
atomically.
--
Glynn Clements <glynn@gclements.plus.com>
On 20/02/07 18:18, Glynn Clements wrote:
Moritz Lennert wrote:
On lines 313 and 324 db/drivers/dbf/tables.c contains a call to 'mv'. This
fails under Windows as the command cannot be found.There is a #ifdef __MINGW32__ between the two calls. If this becomes true,
do we still need the mv calls ?IMHO, that code (and the strikingly similar code in close_new() in
lib/gis/closecell.c) is bogus. It should just be using rename().
Like this ?
I'll have to test on Windows tonight, now that the xdr problem is solved, but on GNU/Linux it works.
lib/gis/closecell.c does not use 'mv', so I guess it doesn't cause any problems in Windows, but I imagine you suggest to get rid of the
#ifdef __MINGW32__
if ( CopyFile ( fcb->temp_name, path, FALSE ) == 0 ) {
#else
if(link (fcb->temp_name, path) < 0) {
#endif
?
Moritz
(attachments)
table.c.diff (833 Bytes)
Moritz Lennert wrote:
>> On lines 313 and 324 db/drivers/dbf/tables.c contains a call to 'mv'. This
>> fails under Windows as the command cannot be found.
>>
>> There is a #ifdef __MINGW32__ between the two calls. If this becomes true,
>> do we still need the mv calls ?
>
> IMHO, that code (and the strikingly similar code in close_new() in
> lib/gis/closecell.c) is bogus. It should just be using rename().Like this ?
Yes.
I'll have to test on Windows tonight, now that the xdr problem is
solved, but on GNU/Linux it works.
rename() is ANSI C, so there shouldn't be any portability issues (it's
already used in several other files).
lib/gis/closecell.c does not use 'mv', so I guess it doesn't cause any
problems in Windows, but I imagine you suggest to get rid of the#ifdef __MINGW32__
if ( CopyFile ( fcb->temp_name, path, FALSE ) == 0 ) {
#else
if(link (fcb->temp_name, path) < 0) {
#endif
Yes; again, this should just use rename().
--
Glynn Clements <glynn@gclements.plus.com>