Re: FAT32 HELP!
- Posted by bytebrain <bytebrain at MINDSPRING.COM> Aug 18, 1999
- 416 views
-------Phoenix-Boundary-07081998- Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable The latest: >Hi Wes, >Is parsing the output of the dir command going too far=3F > >Cheers, >-- Nick Then Wes: >That was my next step, until I found that you can't redirect the >standard >error in dos, so any drive with no files will happily present a FILE >NOT >FOUND even though I'm redirecting output :) > >Bill didn't make it easy... > Hmm. Looks like I need to update the diskutil file. I've been doing some sniffing around, and thus far come up with diddly/squat as far as a *nice* routine is concerned. However, the redirected dir parsing should work fine if you first write a dummy file to ensure that you get no FILE NOT FOUND error. I guess it would simplify parsing as well since you know, in that case, what file name to run a dir for, so you'll only get one return, with no dir dot and dir dot dot stuff in the way either. A zero byte dummy file, deleted immediately afterward, should do the trick. If for some reason you can't write a dummy file (no write permissions, whatever), then I dunno. I'll keep looking. I'm still puzzled about why the carry flag test bombed. If the version of DOS you're running supports FAT32 (as I assume it does) then the durn thing should work. Even if it did not support FAT32, it should have returned CF clear/AL 00h, according to Ralf Browns famous List. Possibly relevant note: According to the aforementioned List with regard to INT21/AX=3D7303h: "This function reportedly returns a maximum of 2GB free space even on an FAT32 partition larger than 2GB under some versions of Win95, apparently by limiting the number of reported free clusters to no more than 64K." So even if you get #7303 to work, you may still need the dir parsing trick to get reliable info. Back to looking, Craig ------------------------------------------ Logic, like whiskey, loses its beneficial effect when taken in too large quantities. --Lord Dunsany -------Phoenix-Boundary-07081998---