23 Feb 95 05:02, Jonathan de Boyne Pollard wrote to David Bannister:

 >>
 >> Simple. In your orginal C++ example you obtained a DASD handle, no
 >> problem there.  It is the _use_ of DosWrite that made your
 >> program fail.  DosWrite is for writing files, not sectors.
 ZZ>>

 JdBP>   With a DASD handle, the entire partition is presented as if it were
 JdBP>   one big file (the documentation for DosOpen says this in almost the
 JdBP>   exact same words).  That's the whole point.

Then your point is incorrect.

Here is what the DOCS have to say about the DASD flag:
========

 The Direct Open bit parameter (OPEN_FLAGS_DASD) is the "Direct I/O
flag." It
 provides an access mechanism to a disk or diskette volume independent of
 the file system. This mode should be used only by system programs and not
 by application programs.

========

It clearly states that the access is *independent* of the _file system_, ie
it is not one big file.  This snippet only proves what I have been saying,
and the whole reason behind OWF, that using this method by-passes the file
system and allows one to over write a locked file.

 ZZ>>
 >> Remember, use the right tool for the job.  If you were to
 >> attempt to use a handle obtained via the DASD flags of a
 >> DosOpen for category 0x09 function then the 0x09 function
 >> would fail.
 ZZ>>

 JdBP>   This is the second time that you've done this.  Why do you keep trying
 JdBP>   to sidetrack the discussion into category 9 calls ?  We're talking
 JdBP>   about DASD handles here, which means category 8 calls.

Jonathan, we are talking about direct access to a disk.  Both 8 and 9 calls
do this, just that one is easier than the other for certian applications.


 ZZ>>
 >> Also, 0x08 & 0x09 calls are not coordinated through the file system
 >> whereas DosWrite calls are.  The reason is that 0x08 & 0x09 calls
 >> communicate directly to the PDD, no file system
 >> intervention -- thus no file locks.
 ZZ>>

 JdBP>   No doubt about the how.  My quibble is with the why.  As I said
 JdBP>   before, I'm with Mike Bilow.  This is a bug.  It may have been an
 JdBP>   "intentional" bug, in that something may not have
worked had it been
 JdBP>   implemented as designed.  Which is why I'm interested in why it should
 JdBP>   work at all.

It is not a bug, as show in the above snippet from the docs about the DASD flag.


 JdBP>   I suspect that it is a nasty workaround to support DOS programs doing
 JdBP>   "BIOS level" or "PORT level" diskette
access via VFLPY, but that's
 JdBP>   only a guess on my part.

It is a means to do low level disk maintenance.  It has a very important
and needed function.

 ZZ>>
 >>  JdeBP> I tend to agree with Mike here.  Going by the published
 >>  JdeBP> documentat a category 8 IOCTL write to disc should fail unless
 >>  JdeBP> you have locke the drive; and if that doesn't happen, it's a
 >>  JdeBP> pretty serious bug.
 >>
 >> I have the published docs here also, all 40lbs.  I see
no references
 >> in there about requiring a call to c0x08 f0x00 in order to
 >> perform and c0x09 call.
 ZZ>>

 JdBP>   And so you shouldn't.  You cannot lock a DASD handle, and then use it
 JdBP>   as if it were a DosPhysicalDisk handle.  You really have to stop
 JdBP>   trying to worm category 9 calls into this discussion.  We're talking
 JdBP>   about category 8 calls.

The reference to 9 is a typo it shoule read 8.  BTW, I can do what I have
been talking about under both 8 and 9 calls.

 JdBP>   Or at least I am.  (-:

You mean hostile?

 ZZ>>
 >> Wouldn't it make sense if this were
 >> the case to have the c0x08 f0x?? also lock the drive as
 >> required or perhaps DosOpen(DASD) do this ?
 ZZ>>

 JdBP>   No, it wouldn't.  What would make sense would be if the implementation
 JdBP>   followed the published specification.

There is nothing wrong with the published spec, it works as documented.  I
have code that proves this.  BTW, have you ran it yet?

 JdBP>   Physical Device Driver reference, section 4.4.11.1 (category 8 Generic
 JdBP>   IOCTL, function 0), under `Remarks' :

 JdBP>      "This function should be called after obtaining a handle from
 JdBP>      DosOpen but before actually accessing the drive."

You are misinterperting the docs.  The operative word is 'should', it is
not manditory.

If you were to further read the docs you would find it says:

=====

 This function locks a drive and is used to exclude I/O by another process on
 the volume in the drive.  The Lock Drive function succeeds only if there is
 one file handle open on the volume in the drive (that is, the file handle on
 which this function is issued).  This is necessary because the desired
result is  to exclude all other I/O to this volume until "Function 01h
- Unlock Drive" is issued.

=====

Notice it says to 'exclude I/O'.  In my sample I do not care to exclude I/O.
If I were writing a disk utility, speaking from experience here, I would
not waht to lock the drive from disk I/O -- makes it awful hard for the
user to access the system.

Are you begining to see it yet?

 ZZ>>
 >> The only time
 >> you need to call c0x08 f0x00 is if you want to lock out
 >> other IO procs.  This is not needed if all you are doing is
 >> reading or writing without regaurd to file synchronization.
 ZZ>>

 JdBP>   You *always* want to ensure filesystem synchronisation.

Oh, Jonathan.

 JdBP>  If you
 JdBP> rewrite  the a directory using category 8 calls, you don't want the
 JdBP> internal  directory entry cache in the filesystem driver to be out of
 JdBP> synch with  the data on disk that you have just written.  Otherwise
 JdBP> there's no  guarantee that it won't come along and undo the changes that
 JdBP> you make.

Try DosResetBuffer with an hFile of 0xFFFFFFFF.  This call will flush all
pending data for all open file handles.  This is getting too easy, next.

In the case of HPFS you can use the above call along with reading &
writing the bitmaps to get the job done.  BTW, I would never attempt to
directly rewrite an HPFS directory on an active drive (on a test drive
yes), too much work to rebalance the sucker -- there *are* ways around
this.

 JdBP>   A lot of low-level UNIX books make the same point, and for much the
 JdBP>   same reason.  You don't want to go mucking around with a raw block
 JdBP>   device when you have mounted it as a filesystem, because that bypasses
 JdBP>   the cache.  There is always the chance that your changes will be
 JdBP>   undone when a dirty block from the cache is written out, for one
 JdBP>   thing.

Sorry but my thing is OS/2. ;-)  See above.

So, have you used OWF yet?

Jonathan, I have no real urge to argue with you, so please can the
hostilities. I have tried to be very nice about all of this, I have made 
that point very very clear.

I have been doing low level disk I/O under OS/2, eps HPFS, since v1.2 --
about six years or so.  I am no Johnny Come Lately.  Over that time I have
come to learn quite a bit -- I know what I can and cannot do.  Anything I
state here I have done, no speculation.

When can I expect delivery on that 2T array? ;-)
(The last 2t array I priced from SGI cost around $5M us... [takes a lot of
space to hold video])

Well, it is almost 2am... Got to run, its been fun.

David

Member of the Judge Stanley Sporkin Fan Club...

--- Snortin' Whiskey/2