[PATCH/RFC] mingw: avoid UAC virtualization
Erik Faye-Lund
UAC enabled, due to UAC virtualization. Disable UAC virtualization
by requesting the asInvoker execution level from the exe-manifest.
Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---
David, perhaps this is partly to blame for the issue you've seeing?
I haven't experienced this issue myself, so I can't say I have any
performance-changes to report (nor have I tried to collect any).
It would be very nice if you could try to rebuild Git for Windows
with this patch applied and see if it improves performance for you.
At least the task manager now reports that UAC-virtualization is
disabled for git.exe after applying this patch. It was listed as
enabled before.
I'm not very proud of the non-portable Makefile-hacks, but this kind
of change would probably be kept far far away from git.git, no?
Makefile | 5 +++--
git.manifest | 10 ++++++++++
git.rc | 2 ++
3 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 git.manifest
create mode 100644 git.rc
diff --git a/Makefile b/Makefile
index 0f340fe..cb13305 100644
--- a/Makefile
+++ b/Makefile
@@ -773,7 +773,7 @@ BUILTIN_OBJS += builtin/verify-pack.o
BUILTIN_OBJS += builtin/verify-tag.o
BUILTIN_OBJS += builtin/write-tree.o
-GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
+GITLIBS = $(LIB_FILE) $(XDIFF_LIB) git.rc.o
EXTLIBS =
#
@@ -2264,7 +2264,8 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
-
+git.rc.o :git.rc
+ windres $< $@
### Maintainer's dist rules
diff --git a/git.manifest b/git.manifest
new file mode 100644
index 0000000..ecea6f7
--- /dev/null
+++ b/git.manifest
@@ -0,0 +1,10 @@
+<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
+<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
+ <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
+ <security>
+ <requestedPrivileges>
+ <requestedExecutionLevel level='asInvoker' uiAccess='false' />
+ </requestedPrivileges>
+ </security>
+ </trustInfo>
+</assembly>
diff --git a/git.rc b/git.rc
new file mode 100644
index 0000000..de40c46
--- /dev/null
+++ b/git.rc
@@ -0,0 +1,2 @@
+#include <winuser.h>
+1 RT_MANIFEST "git.manifest"
--
1.7.3.2.msysgit.0.1.g87dd
Johannes Schindelin
On Mon, 7 Mar 2011, Erik Faye-Lund wrote:
> It would be very nice if you could try to rebuild Git for Windows with
> this patch applied and see if it improves performance for you.
Indeed it would be good if you could try that, David.
> I'm not very proud of the non-portable Makefile-hacks, but this kind of
> change would probably be kept far far away from git.git, no?
We could probably get away with editing /bin/git.exe.manifest in
msysgit.git, just like we did with install.exe, install-info.exe and
patch.exe, no?
Ciao,
Dscho
Erik Faye-Lund
You mean not embedding the manifest at all, but instead shipping it
alongside the executable?
Probably. My approach disables UAC virtualization for non-builtins
also, but that's probably not a big deal. I think I like your approach
better - that way we don't even need a patch to rebase against
git.git, yay ;)
Erik Faye-Lund
Unfortunately, just copying the manifest file to /bin/git.exe.manifest
did not have the same effect for me. UAC virualization is now reported
as "enabled". This is strange to me, though. I probably have to dig a
bit deeper.
Erik Faye-Lund
> On Tue, Mar 8, 2011 at 6:09 PM, David King <dk...@getcollc.com> wrote:
>> On Tue, 8 Mar 2011, Erik Faye-Lund wrote:
>>> In the future, please don't cull the CC-list or top-post. It makes it
>>> harder for other people to follow the discussion.
>>>
>>> I've restored the CC-list and re-quoted the relevant parts.
>
> ... and I forgot to restore the CC after writing the comment, silly me :P
>
Oh GOD, I did it again! :)
Johannes, msysGit developers: Sorry for the mess I've made. I hope
this is still possible to follow.
>> I'm just responding to the e-mail. I'm not sure how things were culled. If I should do something different, please let me know.
>>
>
> You probably chose "reply" instead of "reply all". Please use "reply
> all" when replying to mailing lists.
>
> Unfortunately, some e-mail clients have made the horrendous choice of
> making "reply" the default action, making it easy to either do it by
> mistake or believing it's the right thing to do ;)
>
> We also prefer replies inline (below what you're replying to), because
> that makes it clear what part of an e-mail a comment is a reply to. It
> also allows us to easier remove sub-discussions that is irrelevant
> when we reply. If you'd be able to reply in this style, that would be
> appreciated.
>
>>> On Tue, Mar 8, 2011 at 5:13 PM, David King <dk...@getcollc.com> wrote:
>>>> On Mon, 7 Mar 2011, Erik Faye-Lund wrote:
>>>>> There's been some reports of degraded performance on Win7 with
>>>>> UAC enabled, due to UAC virtualization. Disable UAC virtualization
>>>>> by requesting the asInvoker execution level from the exe-manifest.
>>>>>
>>>>> Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
>>>>> ---
>>>>>
>>>>> David, perhaps this is partly to blame for the issue you've seeing?
>>>>> I haven't experienced this issue myself, so I can't say I have any
>>>>> performance-changes to report (nor have I tried to collect any).
>>>>> It would be very nice if you could try to rebuild Git for Windows
>>>>> with this patch applied and see if it improves performance for you.
>>>>
>>>> I have globally disabled UAC and still see the same performance for msysgit
>>>> under Windows 7.
>>>
>>> OK, that's not a good sign. But did you try to recompile with my
>>> patch? I'm no UAC-expert, but could it be possible that UAC
>>> virtualization is somehow still enabled when UAC is disabled?
>>>
>> After disabling the luafv driver which "Virtualizes file write failures to per-user locations" by launching autoruns.exe going to the Drivers tab and unchecking "luafv", the Windows 7 git status time went down to 3s.
>>
>> I have not tried your patch yet, but if it has the same effect without disabling luafv that would be preferable and a highly valuable addition to the main line. I'm not sure what side effects there may be from disabling luafv.
>>
>> I'll try the patch out when I have a chance.
>>
>
> Thanks, this is very valuable information! The inital report of issue
> 320 in our old (and deprecated) issue-tracker claims that disabling
> "luafv" is the same as disabling UAC virtualization, so this looks
> promising to me.
>
> Please let me know when you have some results! :)
>
Johannes Schindelin
On Tue, 8 Mar 2011, Erik Faye-Lund wrote:
> On Tue, Mar 8, 2011 at 6:21 PM, Erik Faye-Lund <kusm...@gmail.com> wrote:
> > On Tue, Mar 8, 2011 at 6:09 PM, David King <dk...@getcollc.com> wrote:
> >> On Tue, 8 Mar 2011, Erik Faye-Lund wrote:
> >>> In the future, please don't cull the CC-list or top-post. It makes
> >>> it harder for other people to follow the discussion.
> >>>
> >>> I've restored the CC-list and re-quoted the relevant parts.
> >
> > ... and I forgot to restore the CC after writing the comment, silly me
> > :P
>
> Oh GOD, I did it again! :)
Well, it is not exactly your fault.
Neither is it your fault that you try to help, but I get the feeling that
the only person working on this is you, not the ones who should be
interested in doing so. Not even testing your patches.
Ciao,
Dscho
Erik Faye-Lund
While the first part might be true, I don't think this last part is
fair to David. He already stated that he was going to test the patch,
and I don't expect him to turn around an instantly have results
either.
Johannes Schindelin
Okay, sorry. I overreacted. It's just very frustrating to see all those
complaints out there, knowing that if all that time would have been spent
on improving Git on Windows instead, it would really shine by now.
At least it seems that we may reach a turning point with companies: I have
a request for Git consulting now (paid-for). Let's see whether this is a
trend.
Ciao,
Dscho
Erik Faye-Lund
It seems like you might have been on the right track after all.
David, did you manage to recompile and test yet? As I've said, I don't
suffer from this problem so I can't verify it myself...
David King
This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.
Erik Faye-Lund
> It is in my queue to do so and I expect to get to within the next couple of weeks. I haven't built msysgit before, so I'm not sure how much time I should a lot to setting up a build environment.
Ah, but It's trivial, thanks to the wonderful work of Johannes
Schindelin et al! We have a complete development environment set up
for you, you just have to install it.
Download and install "msysGit-netinstall-1.7.4-preview20110204.exe",
open msys bash, cd to /git, apply the patch, type "make install", and
you should have a new build of Git in /bin/ a few minutes later! It
really is that easy :)
> I have disabled the luafv driver which has addressed all of my performance problems, so it's no longer an urgent issue for me. Still, I would certainly like to contribute to the community, time-allowing with my other professional commitments.
>
Oh, come on :)
I've already spent some of my precious spare time trying to help you,
the least thing you can do for me is to tell me if works or not ;)
I understand perfectly that it can be intimidating to build a program
from source for the first time, but given the explanation I gave above
I hope you'll feel a bit easier about it.
David King
-----Original Message-----
From: Erik Faye-Lund [mailto:kusm...@gmail.com]
Sent: Monday, March 14, 2011 5:05 PM
To: David King
Cc: Johannes Schindelin; msysGit
Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
Oh, come on :)
This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.
David King
-----Original Message-----
From: Erik Faye-Lund [mailto:kusm...@gmail.com]
Sent: Monday, March 14, 2011 5:05 PM
To: David King
Cc: Johannes Schindelin; msysGit
Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
Oh, come on :)
This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.
Erik Faye-Lund
You're saying that the installer fails mid-ways, right?
Hmm, I haven't seen anything like that before. The installer should
have a self-contained copy of Git with all the libraries needed for
the initial clone.
On Mon, Mar 14, 2011 at 11:59 PM, David King <dk...@getcollc.com> wrote:
> Okay. I've tried adding msysGit/mingw/bin to my PATH, etc. but I still get this error executing msys.bat. Any other suggestions are welcome.
Did the install finish successfully, or are you trying to repair a
broken install?
>Has anyone ever tried to build on Windows 7 Intel 64-bit architectures previously?
Yes, that's one of my setups. But it works fine for me.
Johannes Schindelin
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
(grins)
On Mon, 14 Mar 2011, David King wrote:
> It is in my queue to do so and I expect to get to within the next couple
> of weeks. I haven't built msysgit before, so I'm not sure how much time
> I should a lot to setting up a build environment.
As has been explained a number of times before, building Git on Windows is
just a matter of downloading the netinstaller from
http://code.google.com/p/msysgit/downloads/list
and running it. It will build Git magically for you. You will have a
command-line window where Git's sources are in /git/. And where
/share/msysGit/add-shortcut.tcl q
will install a shortcut into your quickstart menu (and if you leave the
"q", the script will tell you what other places it can install a shortcut
into).
To make things ridiculously easy, the command-line's prompt will even
_tell you_ to
Run '/share/msysGit/add-shortcut.tcl' to add a shortcut to msysGit.
> I have disabled the luafv driver which has addressed all of my
> performance problems, so it's no longer an urgent issue for me.
That's good. Just make sure that you tell everybody else who has the same
issue to disable the luafv driver, too.
> Still, I would certainly like to contribute to the community,
> time-allowing with my other professional commitments.
Yes, I understand. I also had to stop to contribute to the Git community.
After contributing a stupidly easy way to build Git on Windows, rebase -i,
integrated 3-way merge, forcing Junio to include his colored-diff
patches (after rebasing them), and maybe a few more things.
Ciao,
Dscho
David King
Johannes Schindelin
On Tue, 15 Mar 2011, Erik Faye-Lund wrote:
> > The installer runs for a few minutes and then fails with the error
> > "libiconv-2.dll is missing from your computer".
>
> You're saying that the installer fails mid-ways, right?
Hmpf.
I spent the time neither David nor me have to try to reproduce, because
the bug report contained barely enough information to hazard a totally
wild guess (which must -- by definition -- by almost certainly wrong, and
there fore an absolute waste of time).
No such error occurs here.
Just for reference: I used the
msysGit-netinstall-1.7.4-preview20110204.exe installer.
Following my experiment (which took -- as I mentioned -- time neither
David nor I have), I am inclined to doubt any future bug report that does
not contain a full reproduction recipe with full output (instead, I might
assume that things were done with GitMe-0.4.1.exe on a Windows ME with
1.3MB RAM during the second week after spring's full moon, and
consequently dismiss the bug report as not quite relevant to this decade).
I might even suggest to take 1 more minute to make a slightly less terse
report, in order to spare 25 minutes of developers' time spent on
accomplishing little in the way of reproducing any problem (the result of
which is most likely not favorable to future bug reports).
Ciao,
Dscho
David King
-----Original Message-----
From: David King
Sent: Tuesday, March 15, 2011 12:09 AM
To: 'Johannes Schindelin'; Erik Faye-Lund
Cc: msysGit
Subject: RE: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
-----Original Message-----
From: Johannes Schindelin [mailto:Johannes....@gmx.de]
Sent: Monday, March 14, 2011 7:42 PM
To: Erik Faye-Lund
Cc: David King; msysGit
Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
Hi,
Hmpf.
Ciao,
Dscho
---
Windows 7 Professional 64-bit
Intel Core 2 Quad CPU @ 2.83GHz
8G physical ram
Installing msysGit-netinstall-1.7.4-preview20110204.exe
The installer proceeds normally until the step "make -C gitweb install", then it brings up a dialog "The program can't start because libiconv-2.dll is missing from your computer." Closing the dialog allows the installer to proceed although the dialog repeatedly pops up and you need to repeatedly close it. Specifically the dialog is launched and halts the installer on the following commands:
Make -C gitweb install
make -C git-gui gitexecdir='/libexec/git-core' install
(also at finish of script - is launched 5 times in rapid succession)
The installer finally completes and leaves the msysGit bash shell running, however, any attempt to execute a command from the shell results in the error dialog being launched (usually several times).
The aforementioned library is located in /git/mingw/bin, however adding the absolute windows path (e.g. C:\msysgit\mingw\bin) to my PATH environment variable has no effect on msysGit.
Launching the msys.bat file directly also has the same issue.
----
To add one important piece of data the error dialog indicates "git.exe" as the culprit.
BTW, I think you guys have done a great job on automating the dev environment setup. It's an important step to get developers involved in the project. It just looks like we need to get the kinks worked out with certain OS/architecture combinations. I suspect this is a Win 7 x64 issue. I'll debug it further as time permits.
Regards,
David
Johannes Schindelin
On Tue, 15 Mar 2011, David King wrote:
> Windows 7 Professional 64-bit
> Intel Core 2 Quad CPU @ 2.83GHz
> 8G physical ram
> Installing msysGit-netinstall-1.7.4-preview20110204.exe
>
> The installer proceeds normally until the step "make -C gitweb install",
> then it brings up a dialog "The program can't start because
> libiconv-2.dll is missing from your computer." Closing the dialog allows
> the installer to proceed although the dialog repeatedly pops up and you
> need to repeatedly close it. Specifically the dialog is launched and
> halts the installer on the following commands:
>
> Make -C gitweb install
> make -C git-gui gitexecdir='/libexec/git-core' install
> (also at finish of script - is launched 5 times in rapid succession)
>
> The installer finally completes and leaves the msysGit bash shell
> running, however, any attempt to execute a command from the shell
> results in the error dialog being launched (usually several times).
>
> The aforementioned library is located in /git/mingw/bin, however adding
> the absolute windows path (e.g. C:\msysgit\mingw\bin) to my PATH
> environment variable has no effect on msysGit.
>
> Launching the msys.bat file directly also has the same issue.
>
> ----
>
> To add one important piece of data the error dialog indicates "git.exe" as the culprit.
>
> BTW, I think you guys have done a great job on automating the dev environment setup. It's an important step to get developers involved in the project. It just looks like we need to get the kinks worked out with certain OS/architecture combinations. I suspect this is a Win 7 x64 issue. I'll debug it further as time permits.
Thanks!
>
> Copying /git/mingw/bin/libiconv-2.dll to /git/bin resolves the problem.
> Should this be the default location?
Actually, no... :-) libiconv-2.dll really is a MinGW .dll, so the location
is correct.
> It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to
> c:/msysGit/git.
I think I slowly get what is going on. The UAC apparently prohibits
loading .dll files which are in the PATH instead of the same directory as
the executable requiring them.
> I saved the patch to a file and ran "git apply --stat uac.patch" and it
> results in "fatal: corrupt patch at line 6". Can you assert the
> well-formedness of the patch?
>
> diff --git a/Makefile b/Makefile
> index 0f340fe..cb13305 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -773,7 +773,7 @@ BUILTIN_OBJS += builtin/verify-pack.o
> BUILTIN_OBJS += builtin/verify-tag.o
> BUILTIN_OBJS += builtin/write-tree.o
It appears that the leading spaces were somehow lost. Maybe you do not
have a mailer that lets you save text verbatim (but instead it insists on
trying to be clever and edits the text).
> I was able to install the second two diffs as patches using git apply.
> The first I had to apply manually. I was then able to run "make install"
> without any issues, as you promised - nice.
Great!
> I'll now re-enable my luafv driver and see if this fixed the problem.
Thank you so much for coming back to us, and for being persistent with the
building.
I imagine that we might need a slightly different patch modifying the
manifest such that it allows Windows to load the .dll files also from
/mingw/bin/ and /bin/ even if /git/git.exe is executed. But that really is
beyond my Windows expertise. Kusma?
Ciao,
Dscho
David King
Hi,
Hmpf.
Ciao,
Dscho
---
-----Original Message-----
From: David King
Sent: Tuesday, March 15, 2011 12:21 AM
To: David King; 'Johannes Schindelin'; 'Erik Faye-Lund'
Cc: 'msysGit'
Subject: RE: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
Windows 7 Professional 64-bit
Intel Core 2 Quad CPU @ 2.83GHz
8G physical ram
Installing msysGit-netinstall-1.7.4-preview20110204.exe
The installer proceeds normally until the step "make -C gitweb install", then it brings up a dialog "The program can't start because libiconv-2.dll is missing from your computer." Closing the dialog allows the installer to proceed although the dialog repeatedly pops up and you need to repeatedly close it. Specifically the dialog is launched and halts the installer on the following commands:
Make -C gitweb install
make -C git-gui gitexecdir='/libexec/git-core' install
(also at finish of script - is launched 5 times in rapid succession)
The installer finally completes and leaves the msysGit bash shell running, however, any attempt to execute a command from the shell results in the error dialog being launched (usually several times).
The aforementioned library is located in /git/mingw/bin, however adding the absolute windows path (e.g. C:\msysgit\mingw\bin) to my PATH environment variable has no effect on msysGit.
Launching the msys.bat file directly also has the same issue.
----
To add one important piece of data the error dialog indicates "git.exe" as the culprit.
BTW, I think you guys have done a great job on automating the dev environment setup. It's an important step to get developers involved in the project. It just looks like we need to get the kinks worked out with certain OS/architecture combinations. I suspect this is a Win 7 x64 issue. I'll debug it further as time permits.
Regards,
David
----
Copying /git/mingw/bin/libiconv-2.dll to /git/bin resolves the problem. Should this be the default location?
Erik Faye-Lund
<Johannes....@gmx.de> wrote:
> On Tue, 15 Mar 2011, David King wrote:
>> It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to
>> c:/msysGit/git.
>
> I think I slowly get what is going on. The UAC apparently prohibits
> loading .dll files which are in the PATH instead of the same directory as
> the executable requiring them.
>
I'm running msysGit on Windows 7 (x64) with UAC enabled, and I don't
see this issue. It could be something else that puts my system apart
from David's tough.
>> I saved the patch to a file and ran "git apply --stat uac.patch" and it
>> results in "fatal: corrupt patch at line 6". Can you assert the
>> well-formedness of the patch?
>>
>> diff --git a/Makefile b/Makefile
>> index 0f340fe..cb13305 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -773,7 +773,7 @@ BUILTIN_OBJS += builtin/verify-pack.o
>> BUILTIN_OBJS += builtin/verify-tag.o
>> BUILTIN_OBJS += builtin/write-tree.o
>
> It appears that the leading spaces were somehow lost. Maybe you do not
> have a mailer that lets you save text verbatim (but instead it insists on
> trying to be clever and edits the text).
>
>> I was able to install the second two diffs as patches using git apply.
>> The first I had to apply manually. I was then able to run "make install"
>> without any issues, as you promised - nice.
>
> Great!
>
In the future, you can just use the work/uac-virt branch from this repo:
http://repo.or.cz/w/git/kusma.git
Sorry, I should have mentioned this earlier.
>> I'll now re-enable my luafv driver and see if this fixed the problem.
>
> Thank you so much for coming back to us, and for being persistent with the
> building.
>
Indeed, thanks a lot for the persistence. It's greatly appreciated.
> I imagine that we might need a slightly different patch modifying the
> manifest such that it allows Windows to load the .dll files also from
> /mingw/bin/ and /bin/ even if /git/git.exe is executed. But that really is
> beyond my Windows expertise. Kusma?
>
If you mean to solve the problem described above, I don't really know.
It might be something related. But the whole exercise of the patch is
to disable that UAC virtualization all together. Perhaps if the
git.exe built on install also the requestedPrivileges manifest-stuff?
I guess it would if we ended up merging my branch to 'devel', but I'm
not really sure.
The whole manifest-deal isn't too easy to grok IMO. There's a lot of
documents on it on MSDN, but not many that deal with native code -
it's mostly .NET-related.
David King
From: Johannes Schindelin [mailto:Johannes....@gmx.de]
Sent: Monday, March 14, 2011 7:42 PM
To: Erik Faye-Lund
Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
Hi,
Hmpf.
Ciao,
Dscho
---
Windows 7 Professional 64-bit
Intel Core 2 Quad CPU @ 2.83GHz
8G physical ram
Installing msysGit-netinstall-1.7.4-preview20110204.exe
The installer proceeds normally until the step "make -C gitweb install", then it brings up a dialog "The program can't start because libiconv-2.dll is missing from your computer." Closing the dialog allows the installer to proceed although the dialog repeatedly pops up and you need to repeatedly close it. Specifically the dialog is launched and halts the installer on the following commands:
Make -C gitweb install
make -C git-gui gitexecdir='/libexec/git-core' install
(also at finish of script - is launched 5 times in rapid succession)
The installer finally completes and leaves the msysGit bash shell running, however, any attempt to execute a command from the shell results in the error dialog being launched (usually several times).
The aforementioned library is located in /git/mingw/bin, however adding the absolute windows path (e.g. C:\msysgit\mingw\bin) to my PATH environment variable has no effect on msysGit.
Launching the msys.bat file directly also has the same issue.
This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.
David King
Hi,
Hmpf.
Ciao,
Dscho
----
Regards,
David
----
It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to c:/msysGit/git.
I saved the patch to a file and ran "git apply --stat uac.patch" and it results in "fatal: corrupt patch at line 6". Can you assert the well-formedness of the patch?
diff --git a/Makefile b/Makefile
-----Original Message-----
From: David King
Sent: Tuesday, March 15, 2011 1:06 AM
To: David King; 'Johannes Schindelin'; 'Erik Faye-Lund'
Cc: 'msysGit'
Subject: RE: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
I was able to install the second two diffs as patches using git apply. The first I had to apply manually. I was then able to run "make install" without any issues, as you promised - nice.
I'll now re-enable my luafv driver and see if this fixed the problem.
David
David King
Hi,
Hmpf.
Ciao,
Dscho
----
Regards,
David
----
It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to c:/msysGit/git.
I saved the patch to a file and ran "git apply --stat uac.patch" and it results in "fatal: corrupt patch at line 6". Can you assert the well-formedness of the patch?
diff --git a/Makefile b/Makefile
Erik Faye-Lund
> On Tue, Mar 15, 2011 at 8:28 AM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>> On Tue, 15 Mar 2011, David King wrote:
>>> It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to
>>> c:/msysGit/git.
>>
>> I think I slowly get what is going on. The UAC apparently prohibits
>> loading .dll files which are in the PATH instead of the same directory as
>> the executable requiring them.
>>
>
> I'm running msysGit on Windows 7 (x64) with UAC enabled, and I don't
> see this issue. It could be something else that puts my system apart
> from David's tough.
>
Actually, when thinking twice about it, I might have had this problem
when I installed. Did you try to do "run as Administrator", David? I'm
not sure, but I seem to recall doing that to combat some problem...
>> I imagine that we might need a slightly different patch modifying the
>> manifest such that it allows Windows to load the .dll files also from
>> /mingw/bin/ and /bin/ even if /git/git.exe is executed. But that really is
>> beyond my Windows expertise. Kusma?
>>
>
> If you mean to solve the problem described above, I don't really know.
If my memory above is correct, then we could probably combat it by
setting requestedExecutionLevel to requireAdministrator in the
manifest of the installer. But I'm not at all sure :)
Johannes Schindelin
On Tue, 15 Mar 2011, Erik Faye-Lund wrote:
> On Tue, Mar 15, 2011 at 8:28 AM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> > On Tue, 15 Mar 2011, David King wrote:
> >> It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to
> >> c:/msysGit/git.
> >
> > I think I slowly get what is going on. The UAC apparently prohibits
> > loading .dll files which are in the PATH instead of the same directory
> > as the executable requiring them.>
>
> I'm running msysGit on Windows 7 (x64) with UAC enabled, and I don't see
> this issue. It could be something else that puts my system apart from
> David's tough.
It might be the safe DLL search mentioned here:
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
> > I imagine that we might need a slightly different patch modifying the
> > manifest such that it allows Windows to load the .dll files also from
> > /mingw/bin/ and /bin/ even if /git/git.exe is executed. But that
> > really is beyond my Windows expertise. Kusma?
>
> If you mean to solve the problem described above, I don't really know.
> It might be something related. But the whole exercise of the patch is to
> disable that UAC virtualization all together. Perhaps if the git.exe
> built on install also the requestedPrivileges manifest-stuff? I guess it
> would if we ended up merging my branch to 'devel', but I'm not really
> sure.
It might, indeed, but to reproduce, we need to know what triggers the
error. The cheap and quick and dirty way would be to let the net installer
hard-link libiconv to both /mingw/bin/ and /git/.
> The whole manifest-deal isn't too easy to grok IMO. There's a lot of
> documents on it on MSDN, but not many that deal with native code - it's
> mostly .NET-related.
Right. I also ask myself why putting the required elevation into a
manifest makes this safer than running it with the elevation to begin
with. There are resource editors (and indeed, I hope that we can have
something like that as post-processing step rather than patching the
Makefile to include a resource file) which could be used to put the
manifest into a finished .exe anyway.
Ciao,
Dscho
Johannes Schindelin
On Tue, 15 Mar 2011, Erik Faye-Lund wrote:
> On Tue, Mar 15, 2011 at 8:58 AM, Erik Faye-Lund <kusm...@gmail.com> wrote:
> > On Tue, Mar 15, 2011 at 8:28 AM, Johannes Schindelin
> > <Johannes....@gmx.de> wrote:
> >> On Tue, 15 Mar 2011, David King wrote:
> >>> It was also necessary to copy c:/msysgit/mingw/bin/libiconv-2.dll to
> >>> c:/msysGit/git.
> >>
> >> I think I slowly get what is going on. The UAC apparently prohibits
> >> loading .dll files which are in the PATH instead of the same
> >> directory as the executable requiring them.
> >
> > I'm running msysGit on Windows 7 (x64) with UAC enabled, and I don't
> > see this issue. It could be something else that puts my system apart
> > from David's tough.
>
> Actually, when thinking twice about it, I might have had this problem
> when I installed. Did you try to do "run as Administrator", David? I'm
> not sure, but I seem to recall doing that to combat some problem...
It also might be that PATH is somehow protected against changes...
> >> I imagine that we might need a slightly different patch modifying the
> >> manifest such that it allows Windows to load the .dll files also from
> >> /mingw/bin/ and /bin/ even if /git/git.exe is executed. But that
> >> really is beyond my Windows expertise. Kusma?
> >
> > If you mean to solve the problem described above, I don't really know.
>
> If my memory above is correct, then we could probably combat it by
> setting requestedExecutionLevel to requireAdministrator in the manifest
> of the installer. But I'm not at all sure :)
Hmm. I'd prefer the ln hack if we can prevent requiring admin privileges.
Ciao,
Dscho
David King
-----Original Message-----
From: Johannes Schindelin [mailto:Johannes....@gmx.de]
Sent: Tuesday, March 15, 2011 3:49 AM
To: Erik Faye-Lund
Cc: David King; msysGit
Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
Hi,
Ciao,
Dscho
----
The patch did not alter the performance of msysGit with luafv enabled:
Time to execute "git status" warm start on a repo of 85k files with luafv enabled:
git version 1.7.4.msysgit.0.168.g33778.dirty (patch) - 15.9s
git version 1.7.3.1.msysgit.0 - 16.5s
Is there anything I should do to confirm that the patch had the desired effect (other than the above timings)?
--David
Erik Faye-Lund
....Rats! :(
> Is there anything I should do to confirm that the patch had the desired effect (other than the above timings)?
>
Yes, please verify that if you enable the "UAC Virtualization"-column
in Windows Task Manager and run "git status", "UAC Virtualization" is
reported as Disabled for the git-process.
But this means that we're most likely back to the drawing-board. :(
Erik Faye-Lund
David, did you get around to verify this?
David King
-----Original Message-----
From: Erik Faye-Lund [mailto:kusm...@gmail.com]
Sent: Thursday, March 17, 2011 5:20 AM
To: David King
Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
--
I re-enabled the luafv driver, rebooted, and ran "git status". The UAC virtualization column in Task Manager shows "Not Allowed" for git.exe.
Sebastian Schuberth
Just a small note:
> +git.rc.o :git.rc
> + windres $< $@
This should rather be
git.res: git.rc
windres $< $@
because the binary format generated by the resource compiler out of the
"rc" text format usually has a "res" file extension. Or does the linker
only accept "o" as a file extension?
--
Sebastian Schuberth
Erik Faye-Lund
Yeah, you're right, .res is the naming convention Visual Studio uses,
and is more common. The .rc.o extension is left-over junk from a
failed attempt. But changing the name doesn't change the behavior, so
there not much point fixing it unless we decide to merge some
variation of it.
Erik Faye-Lund
>
> -----Original Message-----
> From: Erik Faye-Lund [mailto:kusm...@gmail.com]
> Sent: Thursday, March 17, 2011 5:20 AM
> To: David King
> Cc: Johannes Schindelin; msysGit
> Subject: Re: [msysGit] Re: [PATCH/RFC] mingw: avoid UAC virtualization
>
> On Tue, Mar 15, 2011 at 2:49 PM, Erik Faye-Lund <kusm...@gmail.com> wrote:
>> On Tue, Mar 15, 2011 at 2:44 PM, David King <dk...@getcollc.com> wrote:
>>> The patch did not alter the performance of msysGit with luafv enabled:
>>>
>>> Time to execute "git status" warm start on a repo of 85k files with luafv enabled:
>>>
>>> git version 1.7.4.msysgit.0.168.g33778.dirty (patch) - 15.9s
>>> git version 1.7.3.1.msysgit.0 - 16.5s
>>>
>>
>> ....Rats! :(
>>
>>> Is there anything I should do to confirm that the patch had the desired effect (other than the above timings)?
>>>
>>
>> Yes, please verify that if you enable the "UAC Virtualization"-column
>> in Windows Task Manager and run "git status", "UAC Virtualization" is
>> reported as Disabled for the git-process.
>>
>
> David, did you get around to verify this?
>
> --
>
> I re-enabled the luafv driver, rebooted, and ran "git status". The UAC virtualization column in Task Manager shows "Not Allowed" for git.exe.
>
Hmm, this is a different status than what I see. I see either
"Enabled" or "Disabled". An article on windows.microsoft.com[1] tells
me that these are the three different statesm, but I haven't yet been
able to figure out what the difference between "Disabled" and "Not
Allowed" are. Would you mind trying without the patch again, and
report what state are reported then?
[1]: http://windows.microsoft.com/en-US/windows-vista/What-do-the-Task-Manager-memory-columns-mean