r.patch non-functional in WinGRASS 6.4 svn on Vista

[cmbarton]

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

[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

[hamish]

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.

[glynn]

Replying to 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?

[neteler]

Replying to glynn:

Replying to 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

[hamish]

Replying to helena:

It is the VISTA UAC problem

Replying to neteler:

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

Replying to 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

[hellik]

Replying to glynn:

Replying to 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

[hellik]

Replying to 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'.

[hellik]

Replying to 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

[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

[hamish]

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

[hellik]

Replying to 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

[hamish]

Replying to 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.

[glynn]

Replying to 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.

[hamish]

Replying to 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

[hellik]

Replying to glynn:

Replying to 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

[glynn]

Replying to 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.

[glynn]

Replying to 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).

[hamish]

Replying to 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

[hellik]

Replying to glynn:

Replying to 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

[hellik]

for the record: the manifest taken from

​http://msdn.microsoft.com/en-us/library/bb756929.aspx

Helmut

[hellik]

Replying to hellik:

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

maybe something for the NSIS-installer-script because it's windows-related?

Helmut

[glynn]

Replying to hellik:

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

How about adding something like the following to the "default" target in the top-level Makefile:

ifneq ($(strip $(MINGW)),)
	find $(ARCH_DISTDIR) -type f -name '*.exe' | \
	while read file ; do \
	    cmd=`basename "$$file" .exe` \
	    sed "s/@CMD@/$$cmd/" generic.manifest > "$$file".manifest ; \
	done
endif

For 7.0, I'd use a pattern rule for "%.exe.manifest" to build a manifest alongside any exe.

It wouldn't be hard to allow the <description> field to be customised, but I'm not sure that really matters. The main thing is to shut UAC up.

[hellik]

Replying to hellik:

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.

also r.le.patch and r.le.setup are marked

Helmut

[neteler]

Replying to hellik:

Replying to hellik:

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.

also r.le.patch and r.le.setup are marked

From ​http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

citation: "Conveniently Accessing Administrative Rights

... Some of the heuristics it uses are as simple as detecting if the image has the words setup, install, or update in its file name or internal version information; more sophisticated ones involve scanning for byte sequences in the executable that are common to third-party installation wrapper utilities...."

...so no surprise...

[hellik]

Replying to hellik:

for the record: the manifest taken from

​http://msdn.microsoft.com/en-us/library/bb756929.aspx

Helmut

see also ​http://trac.osgeo.org/grass/ticket/827#comment:24

​http://msdn.microsoft.com/de-de/library/aa375365%28en-us,VS.85%29.aspx

Helmut

[neteler]

Replying to glynn:

Replying to hellik:

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

How about adding something like the following to the "default" target in the top-level Makefile:

ifneq ($(strip $(MINGW)),)
	find $(ARCH_DISTDIR) -type f -name '*.exe' | \
	while read file ; do \
	    cmd=`basename "$$file" .exe` \
	    sed "s/@CMD@/$$cmd/" generic.manifest > "$$file".manifest ; \
	done
endif

For 7.0, I'd use a pattern rule for "%.exe.manifest" to build a manifest alongside any exe.

It wouldn't be hard to allow the <description> field to be customised, but I'm not sure that really matters. The main thing is to shut UAC up.

I have tried to patch it but get a syntax error. Could you please submit the patch? If it fails, we can still revert.

Markus

[glynn]

Replying to neteler:

I have tried to patch it but get a syntax error. Could you please submit the patch? If it fails, we can still revert.

Try r40977.

[glynn]

Replying to glynn:

Try r40977.

Not quite; needs r40978 as well.

That builds what appear to be valid manifests, but it needs someone with Vista or Windows 7 to test it.

[hellik]

Replying to glynn:

Replying to glynn:

Try r40977.

Not quite; needs r40978 as well.

That builds what appear to be valid manifests, but it needs someone with Vista or Windows 7 to test it.

i've tried this in Grass64 (with attached patch for the make-file), but no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin

Helmut

[hellik]

Replying to hellik:

Replying to glynn:

Replying to glynn:

Try r40977.

Not quite; needs r40978 as well.

That builds what appear to be valid manifests, but it needs someone with Vista or Windows 7 to test it.

i've tried this in Grass64 (with attached patch for the make-file), but no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin

Helmut

now also tested with a fresh-svn-checkout in Grass7, all the manifest-files are built.

Helmut

[glynn]

Replying to hellik:

i've tried this in Grass64 (with attached patch for the make-file), but no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin

You need to add the "$(MAKE) manifests" to the "default" target (see r40977).

[hellik]

Replying to glynn:

Replying to hellik:

i've tried this in Grass64 (with attached patch for the make-file), but no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin

You need to add the "$(MAKE) manifests" to the "default" target (see r40977).

attempts to fix this issue are checked in for Grass64 (r41034) and Grass65 (r41035).

please test by the nightly builds of Grass64 and Grass65.

Helmut

[hamish]

Helmut wrote: (on the -dev ML)

tested with the nightly wingrass-build from today

(WinGRASS-6.4.SVN-r41114-1-Setup.exe) on a WinVista32-box,

both are working now.

ok, thanks. closing bug.

maybe further testing on Win7 is needed?

probably, but that goes for everything. reopen as needed.

Hamish