[GRASS-dev] [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista

GRASS GRASS developer
1

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
-----------------------------------+----------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: r.patch Windows Vista | Platform: Unspecified
      Cpu: Unspecified |
-----------------------------------+----------------------------------------
A student here just ran into an ugly bug on Vista in the most recent
binaries of WinGRASS (stand alone WinGRASS-6.4.0SVN-r39271-1-Setup.exe).

R.patch is complete broken and won't even start. From the GUI, the error
is:

"This application has failed to start because libgrass_gis.6.4.0svn.dll
was not found. Reinstalling this application may fix the problem."

So far, reinstallation has not fixed it.

From the MSys command line, the error is:

GRASS 6.4.0svn (Zac_latlon):C:/GRASS-~1/msys/home/Andrea > r.patch --h
sh: /C/GRASS-6-SVN/bin/r.patch: Bad file number

Hopefully it's a missing file that can easily be remedied in the binary.

Michael

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

2

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
--------------------------+-------------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch Windows Vista
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by helena):

I just posted the exact same issue year ago and then, forgetting the
answer, couple weeks ago again.
It is the VISTA UAC problem - it needs to be disabled (whatever that
means). Most VISTA users have it disabled
because it is causing trouble with other software too, but some don't (I
have two students
who got the error, for others it worked).
It is obvious that we need to change the message that GRASS gives for this
situation because r.patch is so commonly used,
if at all possible. Or we can just hope that VISTA goes away soon?

Helena

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

3

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Changes (by hamish):

  * keywords: r.patch Windows Vista => r.patch, wingrass
  * platform: Unspecified => MSWindows Vista

Comment:

dupe of #118. continue/reopen there.

IIUC "UAC" is user account control. ie it prompts you y/n anytime anything
happens. after 10,000 cases of it crying wolf people tend to shut if off.

http://en.wikipedia.org/wiki/User_Account_Control

AFAIU from ticket #118 this is really a problem of writing to .tmp/ ???
Two problems with that theory: 1) r.patch doesn't use G_tempfile()
directly (maybe the libs do?), 2) why don't other modules that use .tmp/
fail? or for that matter $MAPSET?

So switching off UAC may be the solution, I'm not fully convinced about
the reasons given.

Hamish

ps- please add the word "wingrass" into the keywords so it will
automatically make it onto the wingrass trac wiki errata page.

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

4

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:1 helena]:
> I just posted the exact same issue year ago and then, forgetting the
answer, couple weeks ago again.
> It is the VISTA UAC problem

So why does it only affect r.patch? What does r.patch do that other r.*
modules don't?

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

5

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by neteler):

Replying to [comment:3 glynn]:
> Replying to [comment:1 helena]:
> > I just posted the exact same issue year ago and then, forgetting the
answer, couple weeks ago again.
> > It is the VISTA UAC problem
>
> So why does it only affect r.patch? What does r.patch do that other r.*
modules don't?

Apparently also v.patch is affected at least:
http://trac.osgeo.org/osgeo4w/ticket/107

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

6

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hamish):

> > Replying to [comment:1 helena]:
> > > It is the VISTA UAC problem

Replying to [comment:4 neteler]:
> Apparently also v.patch is affected at least:
http://trac.osgeo.org/osgeo4w/ticket/107

> Replying to [comment:3 glynn]:
> > So why does it only affect r.patch? What does r.patch do that
> > other r.* modules don't?

wild guess: [r|v].patch typically opens many files at once, while most
modules only have a couple files open at one time?
Any reports of r.series having the same troubles in Vista?
Any reports for how it goes in Windows 7?

Hamish

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

7

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:3 glynn]:
> Replying to [comment:1 helena]:
> > I just posted the exact same issue year ago and then, forgetting the
answer, couple weeks ago again.
> > It is the VISTA UAC problem
>
> So why does it only affect r.patch? What does r.patch do that other r.*
modules don't?

from the dev-ml:

{{{
FWIW, I don't consider that to be a particularly good guess. r.patch
doesn't appear to be doing anything remotely out of the ordinary.

Has anyone considered that "patch" might be triggering an anti-virus
rule? More generally, has anyone who can actually reproduce this tried
to perform any meaningful investigation (e.g. checking system logs)?
}}}

tested on a fresh grass64-relbranch-build on WinVista32

r.patch started from Msys:

{{{
GRASS 6.4.0svn (nc_spm_08):c:/ > r.patch
sh: /c/OSGeo4W/apps/grass/grass-6.4.0svn/bin/r.patch: Bad file number
}}}

r.patch started from the wx-gui-command line, the MSVista UAC pops up with
following message (translated from german)

{{{
r.patch.exe
nicht identifizierter Herausgeber - ''no identified publisher''
"C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\r.patch.exe" --interface-
description
}}}

after allowing to continue a next error-message pops up:

{{{
r.patch.exe - Komponente nicht gefunden - component not found
---------------------------
Die Anwendung konnte nicht gestartet werden, weil
libgrass_gis.6.4.0svn.dll nicht gefunden wurde. Neuinstallation der
Anwendung könnte das Problem beheben. - ''The application could not be
started, because libgrass_gis.6.4.0svn.dll could not be found.''
}}}

and afterwards r.patch crashes

Helmut

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

8

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:6 hellik]:
>[...]
>
> {{{
> r.patch.exe - Komponente nicht gefunden - component not found
> ---------------------------
> Die Anwendung konnte nicht gestartet werden, weil
libgrass_gis.6.4.0svn.dll nicht gefunden wurde. Neuinstallation der
Anwendung könnte das Problem beheben. - ''The application could not be
started, because libgrass_gis.6.4.0svn.dll could not be found.''
> }}}
>
> and afterwards r.patch crashes
>
> Helmut

and in the wx-gui-command-output:

{{{
Traceback (most recent call last):
   File "c:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/wxpython/wx
gui.py", line 466, in OnRunCmd

self.goutput.RunCmd(cmd, switchPage=False)
   File "c:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\goutput.py", line 352, in RunCmd

menuform.GUI().ParseCommand(cmdlist, parentframe=self)
   File "c:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py", line 1818, in ParseCommand

xml.sax.parseString(getInterfaceDescription(cmd[0]).decode(e
nc).encode("utf-8"),
   File "c:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py", line 1757, in
getInterfaceDescription

raise IOError, _("Unable to fetch interface description for
command '%s'.") % cmd
IOError
:
Unable to fetch interface description for command 'r.patch'.
}}}

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

9

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:7 hellik]:

from the dev-ml
{{{
Has anyone considered that "patch" might be triggering an anti-virus
rule?
}}}

related(?) information in following link:
http://news.softpedia.com/news/Program-Names-Intimately-Connected-with-
Administrator-Rights-in-Windows-Vista-52813.shtml

=> Program Names Intimately Connected with Administrator Rights in Windows
Vista

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

10

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hamish):

so if you copy/rename "r.patch.exe" to "r.fred.exe", does it then
magically work on Vista?

?!

if so, would a r.patch.bat wrapper script suffer the same fate?

How that would end up with a "Bad file number" error I have no idea.
(does that mean bad a FID? or stderr/stdout not existing, or..?)

Hamish

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

11

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hamish):

does it happen on 64bit? the article seems to indicate this smarts is only
reserved for the 32bit editions. (.... ?!)

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

12

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:9 hamish]:
> so if you copy/rename "r.patch.exe" to "r.fred.exe", does it then
magically work on Vista?
>
> ?!
>
> if so, would a r.patch.bat wrapper script suffer the same fate?
>
>
> How that would end up with a "Bad file number" error I have no idea.
> (does that mean bad a FID? or stderr/stdout not existing, or..?)
>
>
> Hamish

WinGrass65 WinVista32

r.patch.exe renamed to r.helli.exe and started from the msys-shell and the
wx-gui-commandline:

{{{
GRASS 6.5.svn (nc_spm_08):c:/Users/syringia > r.helli input=extr1,extr2
output
=testpatch2
  100%
Erstelle Supportdateien für die Rasterkarte <testpatch2>.
}}}

everything is working, the two rasters were patched. so it's really the
name that causes the problems. what's about a batch-file, i don't know.

i see also in the windows-file-explorer that both r.patch.exe and
v.patch.exe are marked by WinVista with a win-symbol, so Vista really
recognize only by the file-name that there could something
important/dangerous for the system and activates the UAC.

Helmut

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

13

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:11 hellik]:
> r.patch.exe renamed to r.helli.exe and started from the
> msys-shell and the wx-gui-commandline:
...
> everything is working, the two rasters were patched. so it's
> really the name that causes the problems.
...
> i see also in the windows-file-explorer that both r.patch.exe
> and v.patch.exe are marked by WinVista with a win-symbol, so
> Vista really recognize only by the file-name that there could
> something important/dangerous for the system and activates the
> UAC.

sigh. what a complete pile of poo.

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

14

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:12 hamish]:

> sigh. what a complete pile of poo.

+1

For the record, I'll include a copy of the referenced MSDN article:

[http://msdn.microsoft.com/en-us/library/aa905330.aspx\]

Someone who cares about Windows (my "caring about Windows" level just
dropped by a large margin after finding out about this) might want to look
into how to create a "manifest" and whether this actually solves the
problem.

Also:

1. Is this caused (in whole or in part) by GRASS being installed somewhere
other than the "Program Files" directory? If it is, then I care even less.
If there are still problems with spaces in $GISBASE, we should fix them,
rather than expecting GRASS to be installed somewhere else.

2. Is this relevant:
{{{
  Note The "User Account Control: Detect application installations and
prompt for
  elevation" setting must be enabled for installer detection to detect
installation
  programs. This setting is enabled by default and can be configured using
the
  Security Policy Manager snap-in (secpol.msc) or with Group Policy
(gpedit.msc).
}}}
I.e. if you disable that setting, does the problem go away?

If it does, then "problem solved", IMNSHO.

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

15

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:13 glynn]:
> [http://msdn.microsoft.com/en-us/library/aa905330.aspx\]

if it is only for 32bit Vista, that will go away soon.
Any Windows 7 and/or 64 bit users around to test?

> Also:
>
> 1. Is this caused (in whole or in part) by GRASS being installed
> somewhere other than the "Program Files" directory? If it is,
> then I care even less. If there are still problems with spaces
> in $GISBASE, we should fix them, rather than expecting GRASS to
> be installed somewhere else.

I'm not sure if this is relevant at run time or only at build time, but
fwiw the MSys devs seem completely uninterested in fixing spaces in
pathnames issues. They've thrown that class of bugs in the "too hard,
won't even try" pile. I've had a patch in their tracker for 6 months with
no action and 2 of 3 commenting devs recommending "wontfix".

see #629 and,
https://sourceforge.net/tracker/index.php?func=detail&aid=2808978&group_id=2435&atid=102435
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1511614&group_id=2435

for now I have posted the r.patch work-around solution on the Errata
section of the CompileOnWindows trac wiki page.

Hamish

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

16

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:13 glynn]:
> Replying to [comment:12 hamish]:
>
> > sigh. what a complete pile of poo.
>
> +1

+1

>
> For the record, I'll include a copy of the referenced MSDN article:
>
> [http://msdn.microsoft.com/en-us/library/aa905330.aspx\]
>
> Someone who cares about Windows (my "caring about Windows" level just
dropped by a large margin after finding out about this) might want to look
into how to create a "manifest" and whether this actually solves the
problem.
>
> Also:
>
> 1. Is this caused (in whole or in part) by GRASS being installed
somewhere other than the "Program Files" directory? If it is, then I care
even less. If there are still problems with spaces in $GISBASE, we should
fix them, rather than expecting GRASS to be installed somewhere else.

in my case (i don't anything about the original report), i don't install
the WinGrass-installer, i'm building WinGrass in the osgeo4w-stack which
is installed in C:\OSGeo4W. this path is proposed by the osgeo4w-
installer.

>
> 2. Is this relevant:
> {{{
> Note The "User Account Control: Detect application installations and
prompt for
> elevation" setting must be enabled for installer detection to detect
installation
> programs. This setting is enabled by default and can be configured
using the
> Security Policy Manager snap-in (secpol.msc) or with Group Policy
(gpedit.msc).
> }}}
> I.e. if you disable that setting, does the problem go away?
>
> If it does, then "problem solved", IMNSHO.

i've disabled this option, but there is no difference, the problem
resists.

the actual WinGrass-Installer proposes to install WinGrass to c:\Grass. So
maybe, like mentionend in the ms-document that c:\Program Files is a
"safe" site, the WinGrass-Installer should be changed to install the
application into c:\Program Files\Grass to exclude this possible source of
problems? Maybe this should be tested before Grass64-release?

Helmut

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

17

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:14 hamish]:

> I'm not sure if this is relevant at run time or only at build time, but
fwiw the MSys devs seem completely uninterested in fixing spaces in
pathnames issues.

That's mostly only relevant at build time. At run-time, MSys is only
required for shell scripts.

Also, both of the cited bug reports relate to the msys.bat script, which
isn't relevant to GRASS' use of MSys.

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

18

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:15 hellik]:

> in my case (i don't anything about the original report), i don't install
the WinGrass-installer, i'm building WinGrass in the osgeo4w-stack which
is installed in C:\OSGeo4W. this path is proposed by the osgeo4w-
installer.

I'm inclined to say "take this up with the OSGeo4W people". I don't think
that anyone here is in a position to change what's in the OSGeo4W
installer.

> > 2. Is this relevant:
{{{
Note The "User Account Control: Detect application installations and
prompt for
elevation" setting must be enabled for installer detection to detect
installation
programs. This setting is enabled by default and can be configured using
the
Security Policy Manager snap-in (secpol.msc) or with Group Policy
(gpedit.msc).
}}}
> > I.e. if you disable that setting, does the problem go away?
> >
> > If it does, then "problem solved", IMNSHO.
>
> i've disabled this option, but there is no difference, the problem
resists.

In that case, the error isn't what I initially assumed.

> the actual WinGrass-Installer proposes to install WinGrass to c:\Grass.
So maybe, like mentionend in the ms-document that c:\Program Files is a
"safe" site, the WinGrass-Installer should be changed to install the
application into c:\Program Files\Grass to exclude this possible source of
problems? Maybe this should be tested before Grass64-release?

Apart from issues related to UAC, we shouldn't be assuming that the person
installing GRASS has "Create Folder" access on "C:\". Typically, members
of the "Power Users" group have "Create Folder" access for the
`%ProgramFiles%` directory, which allows them to install normal
applications, but anything beyond that may require Administrator status
(and on a network, most users typically don't have Administrator status).

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

19

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hamish):

Replying to [comment:16 glynn]:
> Also, both of the cited bug reports relate to the msys.bat script,
> which isn't relevant to GRASS' use of MSys.

see mswindows/GRASS-Installer.nsi line 418 (etc.) and
mswindows/README.html section 3. The script is used, and those patches
are incorporated.

It occurs to me that if you put yourself in the mindset of MS Win world
then putting so much trust into the file name is not so bizarre. After
all, it's not such a great leap from resting so much trust on the contents
of the last three letters of the filename, why not put meaning on the
first 8+ as well? Not to defend it as very rational or nuthin, or a fit
idea after ~1984 (or whenever the first Macintoshes came out), just
saying.

Hamish

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

20

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:13 glynn]:
> Replying to [comment:12 hamish]:
>
> > sigh. what a complete pile of poo.
>
> +1
>
> For the record, I'll include a copy of the referenced MSDN article:
>
> [http://msdn.microsoft.com/en-us/library/aa905330.aspx\]
>
> Someone who cares about Windows (my "caring about Windows" level just
dropped by a large margin after finding out about this) might want to look
into how to create a "manifest" and whether this actually solves the
problem.
>
> Also:
>
> 1. Is this caused (in whole or in part) by GRASS being installed
somewhere other than the "Program Files" directory? If it is, then I care
even less. If there are still problems with spaces in $GISBASE, we should
fix them, rather than expecting GRASS to be installed somewhere else.
>
> 2. Is this relevant:
> {{{
> Note The "User Account Control: Detect application installations and
prompt for
> elevation" setting must be enabled for installer detection to detect
installation
> programs. This setting is enabled by default and can be configured
using the
> Security Policy Manager snap-in (secpol.msc) or with Group Policy
(gpedit.msc).
> }}}
> I.e. if you disable that setting, does the problem go away?
>
> If it does, then "problem solved", IMNSHO.

if i put the v.patch.exe.manifest and r.patch.exe.manifest (i'll add this
two files to the report) in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin
nearby to v.patch.exe and r.patch.exe, both v.patch and r.patch are
working. :o)

see:

{{{
v.patch input=geology@PERMANENT,streams@PERMANENT output=vectorpatch
Kombiniere Vektorkarte <geology@PERMANENT@PERMANENT>...
Kombiniere Vektorkarte <streams@PERMANENT@PERMANENT>...
Building topology for vector map <vectorpatch>...
Registering primitives...
   1400014035 primitives registered
353881 vertices registered
Building areas...
1832 areas built
907 isles built
Attaching islands...
Attaching centroids...
Number of nodes: 13201
Number of primitives: 14035
Number of points: 0
Number of lines: 8554
Number of boundaries: 3649
Number of centroids: 1832
Number of areas: 1832
Number of isles: 907
Überschneidungen an den Grenzen müssen ge-snapped werden.
Linien, die in mehreren Dateien vorkommen, müssen editiert werden.
Die Header-Informationen müssen auch editiert werden.
v.patch komplett. 2 Vektorkarten kombiniert.
}}}

so the question will be how this could be implemented in the grass-
compile- and build process?

best regards
Helmut

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