v.surf.rst option devi Windows problem

[annakrat]

I have weird problems with devi option on Windows. When I run this command in nc_spm:

g.region rural_1m res=1
v.surf.rst elev_lid792_randpts elev=elev_rstdef_1m zcol=value aspect=asp_rstdef_1m segmax=30 npmin=140

and then try to rerun it again with overwrite flag, I get:

...
WARNING: Vector map <elev_rstdef_devi> is not opened
WARNING: Vector map <elev_rstdef_devi> is not opened
WARNING: Vector map <elev_rstdef_devi> is not opened
WARNING: Vector map <elev_rstdef_devi> is not opened
 100%
Building topology for vector map <elev_rstdef_devi@us
Registering primitives...
WARNING: Vector map is not open for reading
WARNING: Unable to read vector map
WARNING: Unable to close vector <elev_rstdef_devi@use
v.surf.rst complete.

Interestingly, when I try to remove the vector file manually, I can't and I have to close grass session completely and after that I can delete it. So it looks something is left behind.

d.vect had at one point problem to display the vector after the first run but I was not able to reproduce it, now it displays fine.

Any hint what could be wrong? Unfortunately I am not able to reproduce the error on Ubuntu.

[annakrat]

Replying to annakrat:

d.vect had at one point problem to display the vector after the first run but I was not able to reproduce it, now it displays fine.

d.vect gives this, but not always, sometimes it doesn't complain.

WARNING: Size of 'coor' file differs from value saved in topology file
WARNING: Please rebuild topology for vector map <elev_rstdef_cv@user1>
ERROR: Unable to open topology file for vector map <elev_rstdef_cv@user1>

[hellik]

Replying to annakrat:

I have weird problems with devi option on Windows. When I run this command in nc_spm:

g.region rural_1m res=1
v.surf.rst elev_lid792_randpts elev=elev_rstdef_1m zcol=value aspect=asp_rstdef_1m segmax=30 npmin=140

and then try to rerun it again with overwrite flag, I get:

AFAIK overwriting existing files (--overwrite) isn't really working in the windows system architecture as opened files - in contrast to linux/unix - can't be overwritten. Glynn mentioned this on several places in the ML.

[hellik]

Replying to annakrat:

Replying to annakrat:

d.vect had at one point problem to display the vector after the first run but I was not able to reproduce it, now it displays fine.

d.vect gives this, but not always, sometimes it doesn't complain.

WARNING: Size of 'coor' file differs from value saved in topology file
WARNING: Please rebuild topology for vector map <elev_rstdef_cv@user1>
ERROR: Unable to open topology file for vector map <elev_rstdef_cv@user1>

this seems to be a corrupted vector file after the attempt to overwrite it(?).

[wenzeslaus]

Replying to hellik:

Replying to annakrat:

I have weird problems with devi option on Windows. When I run this command in nc_spm:

g.region rural_1m res=1
v.surf.rst elev_lid792_randpts elev=elev_rstdef_1m zcol=value aspect=asp_rstdef_1m segmax=30 npmin=140

and then try to rerun it again with overwrite flag, I get:

AFAIK overwriting existing files (--overwrite) isn't really working in the windows system architecture as opened files - in contrast to linux/unix - can't be overwritten. Glynn mentioned this on several places in the ML.

I don't know what Glynn was saying but I will try to explain from what I know.

Although there are many reasons to mark MS Windows as defective by design, --overwrite can work there as expected and indeed it works in most cases. In cases when there was some error and the data were left in inconsistent state, or more precisely, the process ended when the files were open, MS Windows considers the files as open which on MS Windows means that they cannot be changed or deleted. So, if --overwrite does not work, there is some problem in correctness of the previous process which Linux and other operating systems can easily overcome but MS Windows cannot.

There were few changes recently to make some modules more correct, see r59431 and r62167. But note that comment for r60396 (backport of r59431 to 6.5) is not correct not only because there is probably nothing such as "compilers which zero variables" but also that whether or not file is closed when process is ended is system depended (read: on MS Windows they are not closed on Linux and others they are or it is not important).

[glynn]

Replying to hellik:

AFAIK overwriting existing files (--overwrite) isn't really working in the windows system architecture as opened files - in contrast to linux/unix - can't be overwritten.

1. Overwriting open files and overwriting existing files aren't normally the same thing.

2. There is no inherent problem with modifying open files (i.e. having multiple processes open a file for writing). The problem comes from deleting, renaming or replacing (renaming onto) open files. Unix allows this, Windows doesn't.

The issue boils down to determining why files which were opened by one command are still open when it comes to running a subsequent command.

It may be related to database drivers, as these may persist after the command which started them has terminated (they shouldn't, but past reports suggest that they sometimes do).

Or it may be related to "services" such as indexing, antivirus, version-control shell extensions, etc. Perhaps the initial access results in a notification to the service, which then decides to take a look at the file as soon as it's closed.

[annakrat]

Replying to annakrat:

Replying to annakrat:

d.vect had at one point problem to display the vector after the first run but I was not able to reproduce it, now it displays fine.

d.vect gives this, but not always, sometimes it doesn't complain.

WARNING: Size of 'coor' file differs from value saved in topology file
WARNING: Please rebuild topology for vector map <elev_rstdef_cv@user1>
ERROR: Unable to open topology file for vector map <elev_rstdef_cv@user1>

Driver was not closed, I fixed that in r62300 (backported in r62322) and also added db transaction which speeds up the computation a lot. However, there is still the problem with the coor file. Is this something which could be related to the driver and fixed by r62300 as well or not? The problem is that I couldn't reproduce this problem, it happened only few times to me.

[martinl]

Still an issue?

[annakrat]

I haven't heard of any problems since.