ies,comp.os.os2.programmer.misc   
   05:51:23 GMT)   
   Gecko/20101127 SeaMonkey/2.0.11   
   comp.os.os2.utilities:164 comp.os.os2.programmer.misc:2079   
   From: KO Myung-Hun    
      
   Hi/2.   
      
   Jonathan de Boyne Pollard wrote:   
   >> 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.   
   >    
      
   Can you access to the area over 2GB or 4GB of HPFS partition using   
   HPFS.IFS or HPFS386.IFS with 'L' APIs ?   
      
   Even though you call 'L' APIs, you cannot overcome the defect of IFSes   
   itself if IFSes does not support 64bit IO.   
      
   'L' APIs are for 64bit IO IFSes such as JFS and UDF. Of course, kernel   
   can forward 'L' APIs calls to non-'L' APIs calls.   
      
   Nevertheless, unless all the IFSes are rewritten for 64bit IO, the   
   changed is nothing.   
      
   Of course, I agree that it's the best to use 'L' APIs only without any   
   hack specific to IFSes for the consistency.   
      
   >> 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.   
   >    
      
   What a curious! What is your abstraction layer ? You mean   
   DosRead()/DosWrite() ? Hmm...   
      
   >>> 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.   
   >    
      
   Ok. I didn't release the 0.9.14 of FAT32.IFS. But svn repo on netlabs   
   already has the fixes for the seeking problem.   
      
   See the following changeset.   
      
       http://svn.netlabs.org/fat32/changeset/91   
      
   The cause of seeking problem is not the absence of 'L' entry points.   
      
   It's due to the overflow of 32bits variable. If it's used as a signed   
   variable, it can express up to 2GB, which is the case of FAT32, but if   
   it's as unsigned variable, up to 4GB.   
      
   Due to this, some volume smaller than 4GB worked fine, because it does   
   not cause a overflow of 32bits variable. But some volume larger then 4GB   
   did not work.   
      
   To overcome this limitation, FAT32 introduced sector-io mode as HPFS does.   
      
   That's all.   
      
   'L' APIs and 'L' entry points are not relevant at all.   
      
   > 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.     
      
   FAT is a fallback IFS. And if it uses FSH_DOVOLIO() internally to access   
   a volume, it can work well. This is true for other IFSes as well as   
   FAT32.IFS.   
      
   BTW, I have a question. It can access to the area over 2GB or 4GB ?   
      
   > 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.   
   >    
      
   As I said the above.   
      
   Anyway, I did not release the 0.9.14 because it has not any enhancements   
   for end-users, but just for developers. In addition, FAT32.IFS already   
   has a good replacement for DASD IO.   
   And currently, DosWrite() does not work due to an Access Denied error.   
   What I said "I don't know what the cause is" is this.   
      
   --    
   KO Myung-Hun   
      
   Using Mozilla SeaMonkey 2.0.11   
   Under OS/2 Warp 4 for Korean with FixPak #15   
   On AMD ThunderBird 1GHz with 512 MB RAM   
      
   Korean OS/2 User Community : http://www.ecomstation.co.kr   
      
      
   --- Internet Rex 2.31   
    * Origin: hanarotelecom (1:261/20.999)