TclApp | DLL | CGI - permissions?
Jeff Godfrey
I have a wrapped TclApp CGI program that uses SQLite, so the wrapped
app contains the "tclsqlite3.dll" file. The application runs fine as
a cgi on my personal web server, but testing it on someone else's
server, it seems to silently fail.
After some investigation, I've found that the failure is caused by the
"package require sqlite" command. Interestingly, wrapping the line
with a catch doesn't seem to prevent the failure, nor does it trap any
error messages...
Anyway, I'd assume the problem is related to the handling of the dll
file itself. Unfortunately, I don't know enough about how an internal
DLL file is handled by a wrapped application. I *think* it's copied
to a temp folder somewhere for access by the application (which I'd
guess is the failure point), though I'm not sure. Assuming that's the
case, can I control *where* the DLL is stored? Presumably, I'd want
that located parallel to the wrapped exe itself, (which is in the
"cgi-bin" folder), as I have permissions there.
Any suggestions for debugging and/or fixing this?
Thanks,
Jeff
Jeff Godfrey
news:gHRgi.1781$rR....@newsread2.news.pas.earthlink.net...
> Hi All,
>
> I have a wrapped TclApp CGI program that uses SQLite, so the wrapped
> app contains the "tclsqlite3.dll" file. The application runs fine
> as a cgi on my personal web server, but testing it on someone else's
> server, it seems to silently fail.
After some snooping with FileMon, I have some more info... I can see
that when the application is started, the tclsqlite3.dll file is
written to a temp folder (in my case c:\windows\temp) as a temporary
file (TCLD99.tmp in this case). Do I have any control over the
storage location? I'd assume that a CGI application wouldn't have
permission to store a file there.
Also, assuming the ADMIN will have to give permission for the DLL to
be used (not sure if that's true), it'll probably need a constant
name. By the look of the above temp name, I kind of doubt it'll
always have the same name. Can I somehow provide a constant file name
for the temp copy?
Thanks,
Jeff
Jeff Godfrey
> Can I somehow provide a constant file name for the temp copy?
Continuing to reply to my own thread...
Maybe the simple solution is to not package the DLL within the
application at all. I'd guess I could just land the DLL next to the
application in the cgi-bin folder of the webserver, then just load it
manually in my application code.
That seems simple enough, and likely the direction I'll head, though
I'm still interested in any additional input. It'd be nice if the
temporary storage location and filename of a wrapped DLL could be
specified from within the application's code.
Thanks,
Jeff
Uwe Klein
you are not alone ;-)
>
The way I understand this is that the dll needs to be copied out
to an OS visible part of the FS.
To change the path with random elements used over to a fixed path
you would have to change this in the the wrapping tool you use.
One reason this might be done ( unique path name ) could be
to manage concurrent multiple invocations of your wrappend app.
If you change over to a fixed path you will have to be carefull
with cleanup at exit.
uwe
Jeff Godfrey
"Uwe Klein" <uwe_klein_...@t-online.de> wrote in message
news:f7ddl4-...@klein-habertwedt.de...
> One reason this might be done ( unique path name ) could be
> to manage concurrent multiple invocations of your wrappend app.
>
> If you change over to a fixed path you will have to be carefull
> with cleanup at exit.
Uwe,
Yeah, those are good points - and some that would definitely have to
be considered in a CGI environment. I've already modified my app to
just load a static DLL sitting in the same directory. This seems to
solve the immediate problem, and nicely avoids the ones you mention
above - which I hadn't yet thought about yet. I guess I'm best off
just sticking with that as a solution.
Thanks for the input.
Jeff
Jeff Hobbs
> Anyway, I'd assume the problem is related to the handling of the dll
> file itself. Unfortunately, I don't know enough about how an internal
> DLL file is handled by a wrapped application. I *think* it's copied
> to a temp folder somewhere for access by the application (which I'd
> guess is the failure point), though I'm not sure. Assuming that's the
> case, can I control *where* the DLL is stored? Presumably, I'd want
> that located parallel to the wrapped exe itself, (which is in the
> "cgi-bin" folder), as I have permissions there.
>
> Any suggestions for debugging and/or fixing this?
The DLL is stored in a path derived from the Win32 core APIs GetTempPath
and GetTempFileName. See their docs on how that is manipulated.
An error should bubble up if that can't be loaded properly. I'm not
sure why you shouldn't be able to capture that - it shouldn't fail silently.
Jeff
Jeff Godfrey
"Jeff Hobbs" <je...@activestate.com> wrote in message
news:46843A69...@activestate.com...
> The DLL is stored in a path derived from the Win32 core APIs
> GetTempPath and GetTempFileName. See their docs on how that is
> manipulated.
>
> An error should bubble up if that can't be loaded properly. I'm not
> sure why you shouldn't be able to capture that - it shouldn't fail
> silently.
Thanks Jeff. Yep, I think the "silent failure" was my fault. The
(cgi) app was failing too early for me to have enough machinery in
place to report it properly (with regard to HTTP headers and such).
Thanks again.
Jeff