Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!jarthur!uunet!microsoft!kenr
From: kenr@microsoft.UUCP (Kenneth Reneris)
Newsgroups: comp.os.os2.programmer
Subject: Re: Dectection of HPFS File system?
Message-ID: <59269@microsoft.UUCP>
Date: 23 Nov 90 18:52:58 GMT
References: <1990Nov15.174907.19980@mks.com> <59224@microsoft.UUCP>
Organization: Microsoft Corp., Redmond, WA
Lines: 62




dale@mks.com writes:
| I require a portable and efficient method of determining whether a given
| drive uses the HPFS file system.

dans@microsoft writes:
| something you can do is put the call to DosQFSAttach in a segment that is
| marked as "LOADONCALL" in the .def file.  ...


The default for code and data selectors within an EXE are to
be demand loaded (loadoncall).  They are preloaded when the
application is loaded from remove-able media, or when being run
from accross the network in os/2 versions less then 1.3.   And
since the os will sometimes pre-load the selectors from within
the exe image, you can't really use the "loadoncall" method to
reference the 1.2 (or better) specific function - if for some
reason the selector get's referenced and the function doesn't
exist on the current machine, the program will be crashed by
the os/2 when it fails to get the function address to fixup
the selector.

    a program which uses the "loadoncall" method to reference
    functions not available on the current level of os/2 will
    not work when:
	it's loaded from removable media (floppy drive)
	it's loaded from over the network on os/2 1.0 or 1.1
	or 1.2 when the swap file is on a local hard-disk.
	(1.2 remote booted with a remote swap file would work).
	if a DLL happened to reference the selector

You can use the function DosGetProcAddr to dynamically obtain
the addresses of functions in DLL's, or the OS entry points.
(Note: most of the os/2 functions can only be obtained via
their ordinal numbers.  I believe they are published in an
include file, but for your reference DosQFSAttach is: DOSCALLS.182)

In any event, I wouldn't use QFSAttach for determining the IFS
type.  It doesn't work as you expect accross the network.  It will
return a file-system name of "LAN" if the drive is redirected to
a server.

If you are interested in knowing whether or the file system supports
long files names, you can simply try to create or reference one.
On down-level files systems (or fat) you will get an error when you
try to pass it in a non 8.3 filename.

Another (cheap) method, which was used in a port of LS for
esthetics, looks at the returned FindFirst info. If only the
last-modification date gets returned by the API, the LS program
assumes it was fat and lower cases the filenames before displaying
them; otherwise, it leaves them alone.

    Note: you have to flag the application to be "longnames"
    aware; otherwise, the os will mask out access to non 8.3
    filenames, and will uppercase them before returning them
    to your appliation.  (this is for compatibility with programs
    that do not understand non 8.3 filenames)

                - Ken