wnp@mcomp.UUCP (10/16/87)
nusdhub.UUCP!rwhite (Robert White) writes: > In article <1801@killer.UUCP>, wnp@killer.UUCP (Wolf Paul) writes: > [Stuff Deleted] > > I find it interesting that apparently the MSC stat(2) function does not > > know how to distinguish between devices and regular files, whereas the > > fstat(2) function does make that distinction. I assume they use ioctl > > on the file handle passed to fstat. > > This is SOOOO.... Simple, that the methodologies described > above look quite convoluted.... > > 1) Get the "device status word" using ioctl against the open > file descriptor. [I don't remember the subcommand, so you'll > have to look it up] This is probably how the MSC fstat() function works. The difference between stat() and fstat() is that unlike fstat(), stat() is passed a FILENAME, not a file descriptor, and it is often undesirable to open the file within stat(), because some devices reset when you open them. That is why all these "convoluted methodologies" are of interest. If the matter is SOOOO simple, why does MS-C, which frequently demonstrates greater knowledge of DOS than is available to the public, not make the distinction between files and devices when using stat()? Wolf Paul -------------------------------------------------------- 3387 Sam Rayburn Run, Carrollton, TX 75007 UUCP: ihnp4!killer!wnp ihnp4!{killer, convex}!mcomp!wnp ihnp4!{killer, convex}!mcomp!dcs!wnp Work Phone: (214) 578-8023 Home Phone: (214) 306-9101 ESL: 6283-2882 TELEX/TWX: 910-380-0585
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/19/87)
In article <155300012@mcomp>, wnp@mcomp.UUCP writes: > That is why all these "convoluted methodologies" are of interest. If > the matter is SOOOO simple, why does MS-C, which frequently > demonstrates greater knowledge of DOS than is available to the public, > not make the distinction between files and devices when using stat()? Ask Microsoft why, but ill bet it has something to do with the facts about device drivers under MS-DOS [A few of which are mentioned below] Since the special character devices are not part of the file system, MS-DOS does not handle them "correctly" according to the provisions of stat. Most of the returned valuse are irrational according to the MS-DOS structure. Since MS-DOS is not multi-tasking, barring the use of windows and such, and the proper use of any character device requires you to open it in order for it to be defined in your environment [In multi-tasking extensions to MS-DOS you MUST open the device even if you intend to then bypass the device driver and "do it yourself"] I dont see the harm in opening any device [or file] "for reading" no matter what you intend to do with it. The NULL device is not _NOT_ at all garenteed to be at the head of the device list. The ORIGINAL NULL device usually is, by convention, but any any device can only be opened once when sharing is involved, and more than one device may need NULL. That's why there is a bit in the Device Status Word [Which the standard says you must NEVER set when writing a device driver] which marks it as the "Current NULL Device" The quickest rule of thumb for determining if the device is a character device is: 1) If it's open, use ioctl() 2) If you only have a pathname, look for a colon. If there is no colon, it is probably supposed to be a disk file. If there is a colon, and it is the second character it IS a disk file. If the colon is not the second character it IS either a valid character device, or an invalid file name. 3) If you really want to be shure, open it in compatibility mode as read only. If it opens, it exists and is valid, and then use ioctl() to varify it's device/file standing. The only case I am not SHURE of beyond any doubt is the "no colon at all" as this has bounced around several times. [i.e.colon is/is not required to open character devices.] In most of the "generic MS-DOS extensions" traversing the device list is not at all reliable. [The first example of this that comes to mind is MS-DOS running under unix do supervisor, in which you can't depend on contiguous device driver lists.] Robert.