Gecko/20110303 Thunderbird/3.1.9   
   ies,comp.os.os2.programmer.misc   
   UTC)   
   comp.os.os2.utilities:157 comp.os.os2.programmer.misc:2072   
   From: Jonathan de Boyne Pollard    
      
   > And what do you think about sector-mode of HPFS ? Is it also not any    
   > use at all because it is not independent of filesystem format ?   
   >   
      
   It's certainly not desirable.  I'd much prefer everything to use the    
   "new" (if something from 1999 can be called that any more) OS/2 4.5    
   "raw" paradigm where possible.  Open with DosOpenL, seek around with    
   DosSetFilePtrL, and read and write with DosRead/DosWrite.  No magic    
   filesystem-specific FSCtls or IOCtls at all.   
      
   > I think, you'd better make an abstraction layer for an unified access    
   > to the volume using DASD.   
   >   
      
   I *have* an abstraction layer.  That's why filesystem-specific bodges    
   are undesirable.  The abstraction layer has no knowledge of filesystem    
   format, and it's a godawful bodge to put it in, especially when it's    
   clear from the Toolkit doco that OS/2 4.5 was aiming for a nice clean    
   universal interface free from filesystem-specific bodges.   
      
   >> How close are you to making ordinary sector-level access with    
   >> DosSetFilePtr/DosRead/DosWrite just work as it ought?   
   >>   
   > If you read all the threads, you coulud know that    
   > DosSetFilePtr()/DosRead() worked as expected, but DosWrite().   
   >   
      
   No, they *do not* work as expected.  (And there was no thread from 2005    
   that actually stated otherwise.  Indeed, we have you yourself saying    
   that "I don't know what the cause is." and "HPFS386 also has a similar    
   problem." and "I'll look into [it] more.".)  DosSetFilePtr() still    
   returns ERROR_SEEK, just as it did in 2005.  It's returning ERROR_SEEK    
   for Mark Dodel, and it's returning ERROR_SEEK for Andy WIllis.  They've    
   both independently sent me logs showing this.  (I instrumented CHKVOL to    
   print out the return code from the system call.)  Andy Willis has also    
   kindly tested DosSetFilePtrL and that returns ERROR_SEEK too.  Working    
   on the assumption that they both have the latest release of the FAT32    
   filesystem driver, which I have no reason to doubt, this problem has    
   *not* been fixed and the calls do *not* work as they ought to.  And we    
   even have you stating that HPFS386.IFS, also lacking the FS_CHGFILEPTRL    
   entrypoint, has the same problem.   
      
   Mark Dodel has confirmed that this is FAT32.IFS causing this, by the    
   simple expedient of disabling the filesystem driver and using CHKVOL    
   /FS:FAT, which uses the same access method for reading/writing the    
   volume contents (it being filesystem-agnostic and all).  That worked, he    
   told me.  DosSetFilePtr() didn't return ERROR_SEEK.  And Allan Holm has    
   provided a useful datum, since he has managed to get things to work with    
   the FAT32.IFS driver installed, but on a ~4GiB volume.   
      
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)