Tcl Source Code

The Windows GetFileType() command incorrectly returns
FILE_TYPE_UNKNOWN for a com port when using a "KeySpan
high speed USB serial port" device.  As a result, the
channel logic doesn't realize that the port is in fact
a serial port. 

The attached patch adds a new condition when
determining the file type, where GetFileType() returns
FILE_TYPE_UNKNOWN, but there is no error, the handle is
checked against a serial port and console anyways. 
(It's not clear if the console would ever fall into
this case, but it doesn't hurt).  With this change, the
USB serial port is correctly identified as a COM port
and the serial port-only fconfigure options work as
expected.

In addition to the above fix, this logic was duplicated
in two places, TclpOpenFileChannel() and
Tcl_MakeFileChannel().  The logic was extracted from
both places and combined into a new file static
function FileGetType().

Logged In: YES 
user_id=72656

Added to 8.4.14 and 8.5a4

Logged In: YES 
user_id=72656

mark for 8.4.14

Logged In: YES 
user_id=848625

I'm a user who now needs this patch.
It's over a year old, and doesn't appear to have been
committed as of 8.4.9.

Please, I don't want to throw out my drawer full of
Keyspan adapters.. :(

If I have to, I'll apply it myself and use a homemade Tcl
on all of our machines, but that's going to be really annoying.
Just posting to make sure this patch isn't forgotten.

Logged In: YES 
user_id=75003

David, any news on this one ?
Maybe some to give to Rolf Schroedter as the serial guy ?

Logged In: NO 

According to the documentation for GetCommState() , it
should return zero if it fails (the handle can't be opened
as a COM device.)  This is checked.  Shouldn't this catch
the case of an invalid handle and not return it as a COM
port?  Is there another case in which an invalid handle
could be misidentified?

GetCommState() docs - 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/getcommstate.asp

Logged In: YES 
user_id=7549

For FILE_TYPE_UNKNOWN, we need to make sure an invalid 
handle isn't improperly trapped as a comm port.

Logged In: YES 
user_id=7549

This is really a bug in the USB driver.

Logged In: YES 
user_id=7549

I think this patch is interesting.  A console handle type is 
rather native and shouldn't be something that a custom file 
system driver would get associated to, I think..

I'll play around with this.

File Added - 63725: patch