Fossil

With fossil.exe installed in C:\Windows\system32, "fossil ui" and "fossil server" fail to start the web server. On each attempted access to http://localhost:8080 , the command prompt outputs:

'"fossil"' is not recognized as an internal or external command,
operable program or batch file.

Windows Firewall is off and there are no other firewalls installed.

anonymous claiming to be Arnel added on 2010-10-08 18:03:34:
Are you able to edit your PATH variable and add another folder (e.g., C:\Users\<username>\Documents) where you can transfer fossil.exe instead? Fossil probably does not understand %SystemRoot%\system32, which is what's on PATH for that folder.

wolfgang added on 2010-10-10 12:32:16:
This is not a problem of fossil.

The mentioned error message is a MS Windows message, documenting, that the requested command is not found in the path.

So you should check:

• is the path really correct
• how do you call fossil, MS Windows doesn't use the path variables in all call variants

anonymous claiming to be arichardson (op) added on 2010-10-15 09:10:18:
>Arnel added on 2010-10-08 18:03:34:
>Fossil probably does not understand %SystemRoot%\system32, which is what's on PATH for that folder.

I think you've hit on the problem here. It works perfectly well on XP though, which is why I'm puzzled. I will try your suggestion but ultimately will end up with Fossil back in system32, where (IMO) it belongs.

>wolfgang added on 2010-10-10 12:32:16:
>This is not a problem of fossil.

I believe it is. Please see below for my reasons.

>The mentioned error message is a MS Windows message, documenting, that the requested command is not found in the path.
>
>So you should check:
>
>is the path really correct
>how do you call fossil, MS Windows doesn't use the path variables in all call variants

Looks like you didn't read my ticket. I'll explain again:

At the command prompt, I'm running "fossil ui". ("fossil server" does the exact same thing.) There is a known good, open fossil in the working directory. Fossil opens a web browser (Firefox in this case) and gives it the path "localhost:8080" as expected.

The problem occurs when Firefox accesses localhost:8080. Fossil is definitely listening on 8080/tcp because it reacts to connections on localhost:8080. The way it reacts is to output this error on stdout:

'"fossil"' is not recognized as an internal or external command, operable program or batch file.

instead of returning a web page to the browser.

You're right that this error is generated by the OS, but I believe the flaw is in Fossil. IMO Arnel's suggestion is correct, that Fossil is not interpreting %SystemRoot%\system32 properly. I will now attempt to prove it.

anonymous claiming to be arichardson added on 2010-10-15 09:13:21:
I mean, I will attempt to prove it in 8 hours or so, when I get home from work and have access to my Windows 7 box.

anonymous claiming to be Arnel added on 2010-10-15 11:28:11:
I can confirm "fossil server" works with fossil.exe inside the %SystemRoot%\system32 folder from a Windows 7 box I'm using.

With "fossil ui" I'm getting the "'http:' is not recognized...batch file" message. Which is odd, considering I can run "start http://127.0.0.1:8080/" from within the C:\Windows\system32 folder.

anonymous claiming to be Arnel added on 2010-10-15 11:34:02:
Sorry, I forgot to add: "fossil ui" does provide the error message I described earlier when I ran it from the command-line, *BUT* if I open a browser and go to http://localhost:8080/ it opens the web UI for Fossil.

drh added on 2010-10-15 13:58:28:
I think the problem comes about because Fossil tries to run a copy of itself by calling system() with argv[0] being used as the command name. Apparently on windows, argv[0] is not a reliable name for the program that is being run.

Does anybody have any suggestions for an alternative way to get a windows program to run a copy of itself?

rwilson added on 2010-10-15 15:30:22:
is this recently introduced? i've been using fossil on windows 7 64 bit since it was released with no problems (not counting a few hiccups along the way in the win32 build). i haven't updated my build for about six weeks, so i'm not experiencing this issue (Fossil version [7aae4ef068] 2010-09-03 01:57:41).

drh added on 2010-10-15 16:13:52:
Nothing has changed in this area recently. I think the people that are having problems simply have an unusual windows configuration.

wolfgang added on 2010-10-15 16:37:14:
For my XP machine, argv[0] is correctly filled with the complete path. A windows 7 Home Premium machine shows only the filename(fossil.exe), not the complete path. Both tests used a standard cmd.exe console starting fossil with fossil help ver and fossils install directory in environemt variable PATH. =>

• on XP argv[0] seems to be filled with the complete path, so that the environment is not used
• on Win 7 is only the filename stored in argv[0]. This way it depends on the environment/registry settings, whether fossil is found or not.

The contents of argv[0] can be tested with

fossil help ver

The name of the binary, displayed in the output is replaced with argv[0].

Windows uses diffent ways to find a binary (calling via cmd.exe or calling by explorer,..). So if argv[0] doesn't contain a full path, the error may appear.

I've found a link to some information, how to get the application location:

http://msdn.microsoft.com/en-us/library/ms683197:

DWORD WINAPI GetModuleFileName(
  __in_opt  HMODULE hModule,
  __out     LPTSTR lpFilename,
  __in      DWORD nSize
);

wolfgang added on 2010-10-16 14:48:55:
I think, using pgmptr doesn't really solve the problem. Reading the microsoft msdn pages, i see:

When a program is run from the command interpreter (Cmd.exe), _pgmptr is automatically initialized to the full path of the executable file. For example, if Hello.exe is in C:\BIN and C:\BIN is in the path, _pgmptr is set to C:\BIN\Hello.exe when you execute: Copy

C> hello

When a program is not run from the command line, _pgmptr might be initialized to the program name (the file's base name without the file name extension) or to a file name, relative path, or full path.

anonymous claiming to be arichardson added on 2010-10-18 12:41:22:
>Nothing has changed in this area recently. I think the people that are having problems simply have an unusual windows configuration.

Could you narrow this down a bit? Tricky I know, but did you have something particular in mind? It's a standard Windows 7 Ultimate install. I haven't applied vLite or anything, all the usual parts seem to be there.

anonymous added on 2010-10-19 08:03:50:
Richard, perhaps you refer to this? 44002a7760

I have since set a HOMEPATH (which, OT, I think might be an artifact of AD, which would explain why I've never seen it as I've never had an AD domain at home).

wolfgang added on 2010-10-19 08:26:31:
The original poster uses windir/system32. I think it's not a good idea, to use such an special OS folder for a user installed executable. Especially Vista/Win7 haves special mechanismns to protect this folder. In addition to this: windows uses differrent ways to expand paths while searching executables(see above).

I don't think, that we should try to handle these MS-Windows specific problems.

Many of us do not have any problems with a win7 fossil install. For me the following works pretty good (on different windows versions (XP Home, XP Prof., Win7 HP):

1. install fossil into a fodler in the data area, including executable and repositories (this makes it easy to copy the installation between different computers)
2. add the install directory to the PATH environment variable
3. install a service(nssm/anysrv/..) using the complete path, so the OS path search is deactivated

The problem of the original poster should be solved, if the service uses a fully qualified path instead of giving only fossil (and letting the OS search for the path).

In my opinion, this isn't a problem, which should/can be solved in fossil => Close ticket?

anonymous claiming to be arichardson added on 2010-10-19 08:58:10:
> starting fossil with "fossil help ver"

I'm not sure this test does what you think it does. It didn't work on my Ubuntu workstation:

arichardson@vostro-1:~$ fossil help ver
Usage: fossil version

Print the source code version number for the fossil executable.

When I used the full path, though, it did work...

arichardson@vostro-1:~$ `which fossil` help ver
Usage: /usr/bin/fossil version

Print the source code version number for the fossil executable.

... but using the full path defeats the point, I think. This is on a 32-bit Linux. I do have a 64-bit Linux somewhere but that test will have to wait.

Windows XP (32-bit), same result:

C:\Programs\Windows Resource Kits\Tools>fossil help ver
Usage: fossil version

Print the source code version number for the fossil executable.

C:\Programs\Windows Resource Kits\Tools>%WINDIR%\system32\fossil.exe help ver
Usage: C:\WINDOWS\system32\fossil.exe version

Print the source code version number for the fossil executable.

C:\Programs\Windows Resource Kits\Tools>

I really must change the starting dir. My projects folder would be much more handy.

My 64-bit Windows system is at home and offline, so that test will also have to wait.

anonymous claiming to be arichardson added on 2010-10-19 09:11:14:
>The original poster uses windir/system32. I think it's not a good idea, to use such an special OS folder for a user installed executable.

I can't agree with that. The executable should absolutely not care where it's installed. Why should it stop working in some magic location? If the OS wants to prevent the installation, fine, if group policy wants to prevent it, also fine, but otherwise the executable should work as expected.

I have installed many programs in %windir%\system32 in the past and this is the first time there's ever been a problem.

>Especially Vista/Win7 haves special mechanismns to protect this folder.

The only "special mechanism" is a dialog box saying "you want to do this? really?" and me saying "yes".

>In addition to this: windows uses differrent ways to expand paths while searching executables(see above).

As far as I can see this is the only valid argument against fixing this, that it would require OS-specific code in a "#ifdef _WIN32" block. I hate that kind of thing normally.

anonymous claiming to be arichardson added on 2010-10-19 09:37:52:
>Does anybody have any suggestions for an alternative way to get a windows program to run a copy of itself?

Thinking about it, is this the best way to do it? Could we not just call the cgi function instead of launching a separate instance of Fossil?

anonymous claiming to be arichardson added on 2010-10-19 12:31:31:
Here's another unfinished patch (for src/winhttp.c) to implement the internal call.

https://dreamtrack.dnsalias.com/downloads/self-call.diff

It doesn't trigger the error any more, but neither does it return anything to the browser.

It almost works, now if only I could figure out how to call into main.c from winhttp.c! I'd prefer to do that than separate out the required functions into their own .c file.

drh added on 2010-10-19 12:40:56:
Thanks for the patch, Fatman, but a solution that runs each HTTP request in a thread will be unacceptable. Fossil is designed around processes, not threads. The amount of work required to make Fossil threadsafe would be prohibitive.

See also, http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

I need a way to start a new process (not a thread) running the same binary in Windows 7. Apparently the technique of calling system() on argv[0] or on _pgmptr works for all prior versions of Windows does not work in Windows 7. Nobody has yet explained to me why it doesn't work, and I do not have access to Windows 7 to test it for myself, but apparently it does not. I would prefer to fix the problem, rather than rearchitect all of Fossil.

anonymous claiming to be arichardson added on 2010-10-19 13:12:04:
>a solution that runs each HTTP request in a thread will be unacceptable

Fair enough. I saw "_beginthread" in winhttp.c and assumed it would be ok to use it. I'll think some more.

anonymous claiming to be arichardson added on 2010-10-19 13:23:14:
> Nobody has yet explained to me why it doesn't work

I'd like to know that too. It will affect my work in future.

> I do not have access to Windows 7 to test it for myself

Would it be useful if I set up a Windows 7 VM and you could fiddle with it remotely? My internet connection is fast enough for that, I think, and my server should be able to cope with a small VM. Just an idea there.

anonymous added on 2010-10-19 14:12:33:
I wonder, could this be a related issue?

http://msdn.microsoft.com/en-us/library/ms683197(VS.85).aspx#4

Maybe system() does a GetModuleFileName() call internally. I have been using the 32-bit version of Fossil on my 64-bit OS. If Win7 64-bit screws with 32-bit GetModuleFileName() calls, a simple recompile with MinGW-w64 might fix the problem.

Well, probably not. But I'm hoping for an easy fix. :P

rwilson added on 2010-10-19 23:34:38:
i keep seeing people (including drh) in this thread saying that fossil doesn't work in windows 7. again, it's working for me on windows 7 64 bit, and has always worked. i have it installed in c:\rev\bin, which is different than the OP, but i agree it shouldn't make a difference. you can see my easyunit mirror at http://svn.thereverend.org:8080/easyunit. so what is different about the OP's configuration?

anonymous claiming to be achavasse added on 2010-10-20 13:40:04:
I also have fossil server and fossil ui both working perfectly on two different windows 7 machines. One is running windows 7 32 bit, the other windows 7 64 bit.

In both cases I too have been lazy and just copied fossil.exe to c:\windows\system32.

fossil help ver doesn't show the full path either, only "fossil".

The version I use is 7954ccba68 that I built myself with mingw.

I think the MSDN link a couple comment above is interesting. I built fossil directly on each machine I use it on, so the one I run at home on my 64 bits windows 7 is a 64 bit binary and on my work machine it is a 32 bit binary, so maybe the problem happens only when running a 32 bits binary on a 64 bit windows.

I'm going to try the 32 bit binary I use here at work on my 64 bit windows 7 when I'm home in a few hours and see what happens.

anonymous claiming to be achavasse added on 2010-10-20 18:29:18:
Update: upon verification I actually installed mingw32 on my home computer (the one running windows 7 64bit) and I'm running a 32 bit build of fossil there.

So it's not a problem of 32 bit fossil running on a 64 bit windows.

anonymous added on 2010-10-20 18:51:20:
I would suggest to the person having this problem to use Process Monitor (link below) to log file accesses that are done when running fossil ui.

It will show exactly where windows is trying to load fossil from and what exact problems it encounters while doing so. It might well be something else than a path problem, like a permission problem of some sort.

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

jan.nijtmans added on 2012-08-30 08:58:32 UTC:
proposed fix committed to branch ticket-c8c0b78c84

jan.nijtmans added on 2012-09-24 09:03:58 UTC:
This one should be fully fixed on trunk now