Trying to design low level hard disk manipulation program
|
From: Bill Todd on 28 Sep 2006 09:45 Bill Todd wrote: .... don't > worry about things like collating sequences at all (i.e., just treat the > mess as a simple byte string) - let the GUI handle appropriate sorting > if it wants to for presentation purposes. > > I've almost managed to convince myself that case-sensitive file names > make sense today even though they emphatically did not a couple of > decades ago: please, please disabuse me of that seductive notion if I'm > not being objective. I'll start the ball rolling on that myself: if names that differ only in case are widely-separated in the collating sequence of a humongous directory, any confusing case-only differences can be found only by an exhaustive search (one which might not even be possible via the GUI - or other intermediary - process interface, if that process cannot accommodate the entire directory contents at once). Does this suggest that the file system should collate case-insensitive even while it addresses case-sensitive, so that such potential collisions can be easily found? - bill
From: robertwessel2@yahoo.com on 28 Sep 2006 19:35 Terje Mathisen wrote: > Even 'regular FAT' is an extension of the original FAT (FAT-12), which > used just 12 bits for cluster numbers, thereby limiting it to 4096 blocks. > > This was enough for the original floppies, but had to be extended to > 16-bit cluster numbers to handle the 10 MB hard drive on the IBM XT. > > FAT-32 was a _much_ more significant upgrade, retrofitting lots of new > stuff onto the old file system: > > a) As the name implies, 32-bit cluster/block numbers. Yes. > b) Long filenames. These were implemented with a huge hack, in the form > of multiple Hidden/System Volume labels. Since regular (sub-)directory > scanning code ignored the volume label, this made it possible to stuff > the missing info into the existing directory data structures. No. Long file name support is orthogonal to FAT32, and is/was implemented on FAT16 and FAT12 volumes as well. FAT32 was added with Win98 OSR2, but LFN support was in all version of Win95 (and the base Win98 release), and was also in WinNT. I verified that it was in WinNT 3.51 (I still have an old 486 with that installed for testing purposes - this gave me an excuse to power it on), which predates Win95, and I'm pretty sure that LFN on FAT support was in the first version of NT (3.1). It certainly is a huge hack. FWIW, FAT32 support got added to WinNT well after it was added to Win9x. > c) 10-ms file update timestamps, instead of the 2-sec resolution of > previous iterations. The extended fields (the write and accessed times, as well as the extra resolution on create time) in the directory entry were also added by NT, and again, date back to at least NT 3.51 although I believe earlier). These aren't significant changes, since they just use an 14 byte area in the directory entry that was unused. Probably the biggest "new" thing in FAT32 (excepting the 32 bit cluster numbers) is that the root directory is now a file, like any other directory (instead of a fixed area like in FAT12/16). Beyond that, there are a few new fields in the BPB (and the interpretations of a few of the old ones changed), and there's a trivial additional sector containing the "FSInfo" structure which holds some hints about the state of the FAT32 volume. in fact, the only two fields of significance are the free cluster count - which allows an OS to display a free space number without reading the entire FAT, and the last cluster allocated, which is used as a starting point for the next free cluster. Both fields may be ignored, and are code in such a way that there's no hard if the FSInfo sector is not updated (the filesystem just has to actually scan the FAT when it mounts the volume if the "hint" items are not valid). All in all, its remarkable how little FAT32 changed FAT12/16.
From: Terje Mathisen on 29 Sep 2006 01:52 robertwessel2(a)yahoo.com wrote: > Terje Mathisen wrote: >> b) Long filenames. These were implemented with a huge hack, in the form >> of multiple Hidden/System Volume labels. Since regular (sub-)directory >> scanning code ignored the volume label, this made it possible to stuff >> the missing info into the existing directory data structures. > > > No. Long file name support is orthogonal to FAT32, and is/was > implemented on FAT16 and FAT12 volumes as well. FAT32 was added with OK, thanks! I had forgotten that particular piece of history. > FWIW, FAT32 support got added to WinNT well after it was added to > Win9x. Yeah, I remember that quite well: It meant that regular FAT was the only way to to have a common file system for a dual boot machine. :-( > All in all, its remarkable how little FAT32 changed FAT12/16. :-) Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Benny Amorsen on 29 Sep 2006 04:03 >>>>> "BT" == Bill Todd <billtodd(a)metrocast.net> writes: BT> Does this suggest that the file system should collate BT> case-insensitive even while it addresses case-sensitive, so that BT> such potential collisions can be easily found? What do you mean by collate here? If you say that the results of readdir() or equivalent should be returned in proper alphabetical order, you really have to make that order per-user. My girlfriend and I expect different collations. /Benny
From: Jan Vorbrüggen on 29 Sep 2006 07:30
> Since the source code of the language in question is case sensitive, ....which is already a massive design failure, of course, ... > two of those three are just wrong, Really? Is there anything in the C ISO standard that says that the statement "include stdio.h" must lead to a file names "stdio.h", and not "STDIO.H", or even an entry "STDIO" in a text-library file? Jan |