Date: Sat, 04 Feb 2006 06:29:45 -0400
From: ROLF KNOBEL
To: HECTOR SANTOS
Subject: Re: CGI not working - problem solved
Newsgroups: winserver.public.gamma.testing
Message-ID: <[email protected]>
References: <[email protected]>
X-WcMsg-Attr: Rcvd
X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
Lines: 91

Unbelievable, I hate Windows ;)

After replacing wchttps.dll without luck I tried it on another server and the CGI worked with the gamma AUP. Then I reinstalled Perl again on the real server but the CGI didn't work. After this I logged on as administrator and the

CGI worked... then I played with user access rights for the normal user account but the CGI didn't work.

The real problem here: the user temporary folder was full of cgi*.tmp files (over 65000 files). Deleted all these files and the CGI are working...

Thanks for your help, Hector. Because you didn't have a problem it must have been something on my end.
Rolf

On 2/3/06 4:20 PM, HECTOR SANTOS wrote to ROLF KNOBEL:

<ROLF KNOBEL> wrote in message news:[email protected]...

You got to get a HELLO WORLD now!

No, just a blank page like before.

Odd. Did it even call the batch file? How about adding an echo
statement:

ECHO HELLO > C:\WC6\GOTIT.TXT

Stupid question? Did you try clearing the BROWSER cache?

If you revert WCHTTPS.DLL, to what version does it begin to work again?

451.6 2006-01-31 05:33p 555,828
451.5 2005-10-20 05:20p 555,284
451.4 2005-04-26 10:21a 531,096
451.2 2005-01-09 11:53p 472,468

The above are from my development machine. It should match the current
and older versions saved on the AUP server.

You should have them in your BACKUP-XXXXXX folders.

I think I asked if there was a DELAY issue in the response, like 1-3 seconds. It should fast, maybe a very short delay for Windows to load
the PERL.EXE and its DLLS the FIRST TIME. But after the first time, its should fast processing because of Windows caches. Windows releases

them

after X time when it sees it no longer being used.

So if you really should not see a delay after the first time. That might mean something is interferring with the loading process.

I'm just guessing with that because there was 1 change in 451.4 related
to CGI programs taking a long time to respond with output. WCWEB has a 3 second or so timer waiting for idle output. This only when he sees
nothing. Once it sees something, the timer is off. This was a small
bug here with this timer logic that was fixed in 451.5, that was causing duplicate output with CGI that behaved like so:

Write Output part 1
Delay 3 or more seconds
Write Output part 2

The 451.4 web duplicated part 1 with part 2. That was fixed in 451.5.

451.5 also basically added Environment strings to better support PHP DOCUMENT_ROOT stuff so that you didn't have to set the PHP.INI location
of web or document root directory or something like that. It also
improved how a CGI URL can be called with parameters.

And 451.6 had one fix only to fix the new CGU URL with parameters added
in 451.5.

Try to cause it to fail. In other words, change the SCRIPT ENGINE to an
EXE that doesn't exist. Make sure WCWEB is trying to call it and
fails.

If that works, we know it is calling the EXE.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

--- Platinum Xpress/Win/WINServer v3.1
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)

Date: Sat, 04 Feb 2006 09:09:59 -0400
From: HECTOR SANTOS
To: ROLF KNOBEL
Subject: Re: CGI not working - problem solved
Newsgroups: winserver.public.gamma.testing
Message-ID: <[email protected]>
References: <[email protected]>
X-WcMsg-Attr: Rcvd
X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
Lines: 26


<ROLF KNOBEL> wrote in message
news:[email protected]...

Unbelievable, I hate Windows ;)

The real problem here: the user temporary folder was full of
cgi*.tmp files (over 65000 files). Deleted all these files and
the CGI are working...

Rolf,

Glad you found it! So deleting the temp files cured this? I wonder what
that meant. Do you have many system reboots? WCWEB creates and opens the "cgi*.tmp" temp file using the FILE_ATTRIBUTE_TEMPORARY flag, which
means when the file is closed, Windows is suppose to delete it
automatically. What OS is this? Hmmmmm, I don't have any error
checking on Windows GetTempFileName() call which gives me the next
number to use in "CGIxxxx.tmp" before it is open. I'll read up on it to
see if fails when there are over 65K files. I though it didn't matter.

PS: Can we finally announce the official AUP 451.6 release now? <g>

---
Hector
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)

Date: Sat, 04 Feb 2006 11:03:04 -0400
From: ROLF KNOBEL
To: HECTOR SANTOS
Subject: Re: CGI not working - problem solved
Newsgroups: winserver.public.gamma.testing
Message-ID: <[email protected]>
References: <[email protected]>
X-WcMsg-Attr: Rcvd
X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
Lines: 37

On 2/4/06 9:09 AM, HECTOR SANTOS wrote to ROLF KNOBEL:

<ROLF KNOBEL> wrote in message news:[email protected]...

Unbelievable, I hate Windows ;)

The real problem here: the user temporary folder was full of
cgi*.tmp files (over 65000 files). Deleted all these files and
the CGI are working...

Rolf,

Glad you found it! So deleting the temp files cured this? I wonder what that meant. Do you have many system reboots? WCWEB creates and

opens the

"cgi*.tmp" temp file using the FILE_ATTRIBUTE_TEMPORARY flag, which
means when the file is closed, Windows is suppose to delete it automatically. What OS is this? Hmmmmm, I don't have any error
checking on Windows GetTempFileName() call which gives me the next
number to use in "CGIxxxx.tmp" before it is open. I'll read up on it to
see if fails when there are over 65K files. I though it didn't matter.

No, there aren't many system reboots. I reboot the server after a Windows update requires it otherwise the server runs without restarts. It's a Windows 2000 Server. I saw really old cgi*.tmp files (I believe the oldest was from june 2005). I'll take a look if the files are from a specific script or if no temp
files are deleted.

PS: Can we finally announce the official AUP 451.6 release now? <g>

I think yes ;) Sorry, it was a really bad timing for this problem...

Rolf

--- Platinum Xpress/Win/WINServer v3.1
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)

Date: Sat, 04 Feb 2006 11:57:25 -0400
From: HECTOR SANTOS
To: ROLF KNOBEL
Subject: Re: CGI not working - problem solved
Newsgroups: winserver.public.gamma.testing
Message-ID: <[email protected]>
References: <[email protected]>
X-WcMsg-Attr: Rcvd
X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
Lines: 44


<ROLF KNOBEL> wrote in message
news:[email protected]...

No, there aren't many system reboots. I reboot the server
after a Windows update requires it otherwise the server runs
without restarts. It's a Windows 2000 Server. I saw really old
cgi*.tmp files (I believe the oldest was from june 2005). I'll
take a look if the files are from a specific script or if no temp
files are deleted.

yes, it would of help (provide some background intelligence information)
to see what kind of cgi*.tmp, how old? Zero size? etc.

Yes, it has to be deleted at ALL times after the CGI is finished. This
is the logic and it must be deleted unless something else is preventing
it. There is nothing wrong with this delete logic.

I am investigating how WCWEB will work when there is 65K files and how
this could or might be related to files not being deleted.

What I found is the GetTempFileName() will FAIL if there are no more
unique numbers to assign when there are over 65K files. Since this
never expected to fail, there was no ERROR checking for this in
WCHTTPS.DLL.

I can add additional logic to check this, but it doesn't explain how it
is possible for 65K CGI*.TMP were never deleted in your case over the
year. Meaning, if GetTempFileName() failed, then there was NOTHING to
delete :-)

Do you have any WCHOSTFAULT.LOG entries? I suspect if you do, there will
be alot of them corresponding to the CGI attempts. Of course, I don't
expect you to be able to repeat this now so don't worry about it
anymore. But do tell me if you do have a WCHOSTFAULT.LOG with entries
that look to match the times when the CGI failed this past week. If so,
that might give me some feedback to work with while I take a final look
at the cgi logic.

Thanks

---
Hector
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)