[GRASS-dev] [GRASS GIS] #2452: v.surf.rst option devi Windows problem

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452&gt;
GRASS GIS <http://grass.osgeo.org>

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by annakrat):

Replying to [ticket:2452 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>
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by hellik):

Replying to [ticket:2452 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by hellik):

Replying to [comment:1 annakrat]:
> Replying to [ticket:2452 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(?).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by wenzeslaus):

Replying to [comment:2 hellik]:
> Replying to [ticket:2452 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).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by glynn):

Replying to [comment:2 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

#2452: v.surf.rst option devi Windows problem
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.surf.rst | Platform: MSWindows 8
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by annakrat):

Replying to [comment:1 annakrat]:
> Replying to [ticket:2452 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2452#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>