[Xitami] devices problem

[Ewen McNeill]

In message <006401c190c5$a0299000$1564a8c0@troy.ozin.foo>, "Jason Ozin at Techni
ca Solutions" writes:
> > I was going to ask if you had problems with AUX.
>
>Ok I've now done the definitive test. I created a new printer (generic text
>only) and told the OS it was on COM1 (it didn't actually exist you
>understand). I then entered www.xxx.com/com1 into Opera and lo and behold it
>crashes. The same for AUX. So that is it I'd say. Your theory is correct.

Okay, it sounds like the fix in 2.4d9/2.5b5 narrows it down to the
situation where:
(a) the device actually exists and is being used (eg, a printer is
    installed); and
(b) the timing of the access is "unlucky"

> > The other interesting factor from your detailed post is that it doesn't
> > happen every time, only when you've hit refresh a lot.  That screams
> > "race condition" to me
>
>Well... yes but don't get too stuck on this as I can make it happen on the
>very first go sometimes as well. I did with the COM1 test above.

_Sometimes_ "first go" is fine -- that can still easily be a race
condition, it's just that the timing happened to be right the first
time.

If it was _always_ first time, then it wouldn't be a race condition
(since it'd be repeatable quite easily), but it doesn't sound like
that's the case here.

The "device problem" handling in Xitami 2.4d9/2.5b5 (same code in both;
testing one version or the other is fine folks -- but no earlier
versions have the fix) works like this:

Try to open the path name given
If it opened:
   Ask Windows "what type of file have I opened?"
   If Windows says "a disk file": it's not a device
   If Windows says anything else: it's probably a device, ignore it
If it did not open:
   Assume that it isn't a device

If the path name is not a device:
   Open the file for reading (to start sending the results out)

The catch is that the file is being opened twice, once to check what
type of file it is, and once to actually access the data.
(Unfortunately we need to do this because only the special Windows API
call will let us ask if it is a device file, but everything else in
Xitami uses the more portable C standard file handles.)

If "something changes" between these two situations, so that the first
open fails, and the second one succeeds, then I think we'll get the
problem we're noticing here (at least if the path name is a device
file).

And my guess is the "something changing" is something like another program
having the device open (blocking us out, so we assume it is not a device)
when we first try to find out if it is a device, and but it has closed it
(freeing up the device) by the time we try to open it again to read from
it.

Unfortunately the Windows API documentation doesn't have much detail
about doing this type of test, or what types of errors we can get back
from the first open attempt, so we're left to guess what might happen.
(It would be _really_ handy for instance if the first open gave us an
error of "someone else is using that device right now" for instance,
then we could know if it was a device even if the open failed.)

I've got a couple of ideas to try, although as I commented, I'm somewhat
hampered by the fact that I can't reproduce the problem...

Ewen

-- 
Ewen McNeill, Technical Consultant, iMatix Corporation  www.imatix.com