Date: Wed, 30 Dec 1998 10:48:59 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Martin Str|mberg cc: djgpp-workers AT delorie DOT com Subject: Re: FAT32X and DJGPP In-Reply-To: <199812292017.VAA06409@father.ludd.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Note that I've redirected this to djgpp-workers. On Tue, 29 Dec 1998, Martin Str|mberg wrote: > Hmm. Should we improve the "Type" field from {hd,fd,cdrom} to {FAT12, > FAT16, FAT32, ISOFS, ...}? Or will this cause to much rework? There's nothing magic about these names, a discussion held during development of the current version of mntent.c concluded that there's no standard that says what should the TYPE field be. So I picked the ones a PC user will understand. For example, ISOFS or even CDFS (which is what Unix systems return) will probably be less obvious. Therefore, there should be no problem to change these names, but I think we should keep them at 5 letters or less, since otherwise the report printed by `df' gets ugly. One problem with FAT16 types of name is that they don't tell what kind of drive is that, whereas "fd" and "hd" do (I think "floppy" is better than "fd", but it's longer than 5 letters). > It seems I can't find how to detect FAT32 (vs. FAT16) from RBIL (Ralf > Brown's Interrupt List). Any ideas? This is one of the problems that should be solved. We had a discussion about this some time ago on djgpp-workers (search the djgpp-workers mail archives for the subject "Should size_t become unsigned"), and as far as I remember, two possible solutions popped up: - read the boot sector where the size of the FAT is recorded; - use an FCB-oriented file function which doesn't work with FAT32. Personally, I like the latter solution better, even though I'm told that the former one doesn't require to lock the volume (Windows 9X requires to lock the volume, which is a very slow and anti-social operation, for direct disk access, but only for writes, not for reads). However, the solution to this problem has never been finalized IIRC, so it might well be there are other possibilities as well. In particular, it remains to be seen how expensive the FAT32 detection is. For `statfs' calls this problem might not be too important (how many times do you call it in a program, anyway?), but if we are to use FAT32-specific features in lseek and write, then it better be fast. > From RBIL it seems it's only possible to seek using the old seek call > (I can't find any FAT32 seek). There is none, AFAIK. > This means 2^31 per seek operation. Is this so? Yes. > I suppose the workaround is to let _llseek do several seeks > to fullfill the seek operation. Yes, that seems to be the only way. > > And while at that, please see if the Int 21h call that is supposed to > > return the starting cluster number of a file works on FAT32. (See the > > function `_ioctl_get_first_cluster' on stat.c in the library sources.) > > RBIL implies that it should work on any modern DOS version, but I was > > unable to get it to work on DOS 5.0, 6.20, or 7.0 (it always fails). > > I can't get anything else than fail from _ioctl_get_first_cluster() or > the underlying dpmi_int() calls. Is RBIL correct (perhaps some typo or > something)? I suspect there's either something incorrect in RBIL, or some subtle point in how that call should be issued that isn't described. I tried some time ago to write to Ralf Brown and ask him about this call, but got no response. Maybe you could try asking him again? It's a pity that such a promising service cannot be used by DJGPP.