goinstall fails on Windows, sh: ./goinstall: Bad file number #1826
Labels
Comments
I can't reproduce your problem. I hit different problem: C:\>goinstall github.com/dchest/gotweet/src goinstall: github.com/dchest/gotweet/src: mkdir c:\a\src\pkg\github.com\dchest\: The system cannot find the path specified. C:\> It seems os.Mkdir only handles '/' path delimiters, but not '\'. Perhaps you have some ideas how to reproduce your problem. Perhaps you can put fmt.Printf() statements inside goinstall to see where it fails and why. Thank you. Alex Status changed to WaitingForReply. |
|
Owner changed to @alexbrainman. |
I have tried to add printf statements but nothing prints. I continue to get: sh: ./goinstall.exe: Bad file number The exit code is 126. This seems like an error with the operating system launching the program itself. I have tried to take all of the init() functions and var definitions that may be causing this problem and put them into a test.go program, so far I cannot make the test.go program fail as goinstall does. Is it possible to obtain a copy of your goinstall.exe to see if your identical goinstall.exe fails on my machine? That may lead somewhere. |
I'm pretty sure you're right about some executable is not right, but I'm trying to understand who calls who. Could you, please, use full path when running goinstall, and also use -v parameter, and report the result: C:\Development\Go> C:\Development\Go\src\cmd\goinstall\goinstall -v github.com/dchest/gotweet/src Thank you. Alex |
When I run this command from the cmd.exe prompt, I first get a User Access Control dialog from Windows asking if it is OK for this program to make changes to my computer. If I choose no, I get an access denied error. If I choose yes, a new command prompt window appears for a split second and then disappears. Windows then shows a dialog box stating the program was not installed properly, do I wish to reinstall it. When running this command from the MSYS shell (sh.exe) I continue to get the original error except with the full path: sh: /c/Go/bin/goinstall.exe: Bad file number |
Please do this: 1) change to goinstall source directory cd $GOROOT/src/cmd/goinstall 2) delete the file make clean 3) make sure it is gone ls -l goinstall.exe 4) build it again make all 5) make sure it is there (send us the output) ls -l goinstall.exe 6) run it ./goinstall.exe -v github.com/dchest/gotweet/src also, please tell us what 8g -V say. Thank you. Alex |
Seeing this error it just dawned on me what is happening. It's all in the name! User Access Control (UAC) has something it calls Installer Detection Technology, please see: http://technet.microsoft.com/en-us/library/dd835540%28WS.10%29.aspx ... Scroll within the page to the section titled "Installer detection technology" Basically Windows sees the word "install" in the executable and automatically determines that the executable requires Admin privileges and thus tries to elevate the executable permission. I renamed the executable to goinst.exe and I now get the error that you are getting... goinst: github.com/droundy/goopt: mkdir C:\Go\src\pkg\github.com\droundy\: The s ystem cannot find the path specified. I'll bet that you have UAC disabled and that is why you are not seeing the initial problem I and others are reporting, but that's just a guess. I have not read entirely about the Installation detection technology but I believe it is possible to embed a resource stating this program does not require elevated privileges. I will do more research on this and report back. If so, the new patch on the mailing list dealing with embedding resources via the linker could be used or possibly a .exe.manifest file could be created or the command name could be renamed (not a good thing because then there are platform differences in fundamental commands). I also have an idea about why we are now getting the above error. I will submit a patch a little later today (wee hours in the morning here, need sleep before work starts :-) |
I tried to use the code-login process to submit this patch, but on Windows the install of Mercurial continues to state: *** failed to import extension codereview from C:/Development/Projects/go/go/lib /codereview/codereview.py: No module named HTMLParser I have no idea why, I do not use Mercurial or Python other than for the go checkout. Anyway, I have attached a manifest file that causes goinstall.exe to not request elevated privileges. This manifest file would have to be installed in the same location as goinstall.exe to function. Also, when testing, you must either recompile goinstall.exe or update it's create date/time. Windows caches any .manifest file and if the goinstall.exe timestamp has not changed since your last execution it does not bother looking for a new .manifest file. I have also attached a .rc file when used with the resource file patch: http://golang.org/cl/4516055/ would embed the .manifest into the executable so only 1 file has to be installed into Go/bin. This solves the problem with this issue. It does not, however, solve other problems with Go install that you have run into as well. Should discussion/work on those issues continue here? BTW... after getting past the directory problem there are other problems as well. Attachments:
|
I was able to create a code review: http://golang.org/cl/4519062/ |
As to the other issues, they deal with path separators and it seems that the active code review: http://golang.org/cl/4252044/ .. should fix this problem. |
I'm reluctant to make any changes. The fact that naming program goinstall.exe put you on the "black" list seems wrong to me. Even worse, you could circumvent the system by attaching bit of xml data to your exe file. I believe goinstall.exe users would have to be smart enough to be able to switch "UAC Architecture" off, if so desired. In my mind, maybe some documentation in goinstall documentation should do the trick. But I live in a "real world" <g>, I'm happy to accept whatever solution there is to it. Russ, what do you say? Alex |
Just so it is understood, It is Windows attempt to do the right thing under normal situations. Not all programs request elevated rights, thus Windows sees that it is probably an installer, thus it asks the user, "Is it OK for this program to change your computer?" and if they answer yes, then it elevates the rights given to the program to that of an administrator. If, however, you tell Windows that this program does not require elevated rights (what the .manifest file does), then Windows does not bother asking the user NOR does it give the program elevated rights. So, nothing is circumvented. You are just helping Windows understand your programs intentions. Including the .manifest does not give your application elevated rights w/o asking the user. The names on the "black" list are install, setup and update. Now... with that said, I am in agreement that if the name is changing in a few months then nothing should be done right now. In regards to documentation, you should not instruct someone to turn off UAC. It has huge benefits in system safety. If you are going to do anything with documentation I would state that there is a known problem with the naming of goinstall on Windows machines where UAC is enabled (the default, BTW). To get around these problems rename the executable to goinst.exe or something to that effect. |
I won't argue with you. Just want to state my personal point of view. How is goinstall.exe is different (apart from having name that MS don't like) from any other? It is not "requesting elevated rights" from OS. It does what it is designed to do. Questions, like "Is it OK for this program to change your computer?" are silly, because every program changes your computer, some program write to memory, others to disk and so on. I don't know much about UAC to make a judgement, but what I've seen so far, tells me to stay away from it. I think it is attempting to solve hard problems by simple/silly solutions. Alex |
In a nutshell it's sudo, that's all. Telling someone to disable UAC could be seen as telling someone to just use root all the time. In some Linux distributions when you go to install a software package, for example, it asks for the root password. That's the same thing UAC does. It can be silly at times, like we discovered in this case but it was Microsoft's best attempt to make old (non-UAC aware apps) UAC compliant, that's all. Probably solves the problem most of the time and then in situations like ours just causes problems... in the end, naming the executable gomake solves all these problems, so it's a good solution. No reason to argue, just offering a more detailed explanation of UAC for everyones understanding. |
Just put the following file into the same directory as the goinstall.exe and you're fine Attachments:
|
You will need to update (change goinstall.exe timestamp) as Windows caches the last read manifest file based on the executables date. So, if you ran the executable, Windows loaded any manifest file and stored its results (or no results if no manifest file). Then running the executable again Windows will just look at its last read manfiest even if empty. Jeremy |
I added goinstall.exe.manifest and updated the timestamps and that got rid of the
annoying dialog. But goinstall really doesn't seem to understand windows paths:
C:\Go\bin>copy /b goinstall.exe.manifest +,,
Access is denied.
0 file(s) copied.
C:\Go\bin>copy /b goinstall.exe +,,
1 file(s) copied.
C:\Go\bin>cd c:\goeg\src
c:\goeg\src>set GOPATH=C:\goeg
c:\goeg\src>goinstall *.*
2011/07/01 12:40:59 Invalid GOPATH "C": must be absolute
goinstall: *.*: open C:\Go\src\pkg\*.*: The filename, directory name, or volume label
syntax is inco
rrect.
c:\goeg\src>set GOPATH=\goeg
c:\goeg\src>goinstall *.*
goinstall: *.*: open C:\Go\src\pkg\*.*: The filename, directory name, or volume label
syntax is inco
rrect.
c:\goeg\src>goinstall myapp1
bash: === cd \goeg\src\myapp1; bash gomake -f- install
--- exec: "bash": executable file not found in %PATH%
goinstall: installing: running bash: exec: "bash": executable file not found in %PATH%
c:\goeg\src>
|
1) treating of GOPATH was fixed: http://code.google.com/p/go/source/detail?r=4fae10f46847 2) "goinstall *.*" will not work on windows, "goinstall *" work on unix because unix shell converts * into the list of files/directories (goinstall does not see *), windows does not do that. Perhaps "goinstall ."? 3) last problem is goinstall trying to execute gomake bash script, therefore it is looking for bash in your %PATH% and it finds nothing. That problem will go away once you will use newer version that can build without make. Alex |
|
Issue #2290 has been merged into this issue. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by jcowgar:
The text was updated successfully, but these errors were encountered: