I downloaded and built Lewin Edwards' DOSFS package. It builds without a flaw. I would love to get up and running quickly for desktop testing but the disk image file is missing from the package and that requires me to build my own.
I'm very unknowledgeable about FAT file systems. That fact makes it difficult for me to create one from scratch.
Would anyone have a sample FAT32 diska image file that would work with DOSFS for local desktop testing?
I'd ask Lewin himself but he warns emphatically to not bother him with DOSFS questions. (Lewin, can you make an exception?)
Just format a USB thumb drive with the "/FS:FAT32" option from the command line. No problem so long as it's over 32MB in size and less than 2GB.
Or do the same for a hard disk partition. Note that you cannot format a floppy FAT32, since it's not possible to put enough clusters on a floppy to get past the 65536 cluster threshold so that it will be detected as a FAT32 volume.
What I actually say is that you can ask all you want, but I don't guarantee a response, and furthermore if I do respond and it involves a bugfix, then the bugfix is not your private property, it is added to the public source tree.
Anyway - There is a 1GB FAT32 disk image at . It is about a 5.5MB download; unused sectors were zeroed before imaging.
There must be a step missing here. I can format a USB flash drive but DOSFS requires an image file (HOSVER is defined in the makefile) that will be used to mimic the volume.
I connected a 512M USB flash drive on drive G and formatted it for FAT32. Then I entered "dosfs g:\" at the command line and was given a "Cannot attach image file 'g:'" error. It's looking for a true blue file just for testing purposes.
Is it possible there's a way to extract the image file from the USB flash drive?
Just in case you haven't tested with a FAT16 image, here is one with these parameters (output of 'partread' which is my version of 'partscan'):
Partition 0 start sector 0x00000011 active 80 type 04 size 0000A307 Volume label ' '
4 sector/s per cluster, 1 reserved sector/s, volume total 41735 sectors.
41 sectors per FAT, first FAT at sector #18, root dir at #100. (For FAT32, the root dir is a CLUSTER number, FAT12/16 it is a SECTOR number)
512 root dir entries, data area commences at sector #132.
10400 clusters (21299200 bytes) in data area, filesystem IDd as FAT16.
file: 'TEST DIR' DIR 0 2 file: 'FOO TXT' 17 3
Input path to list: TEST.DIR
Directory of TEST.DIR file: '. ' DIR 0 2 file: '.. ' DIR 0 0 file: 'BAR TXT' 24 4
Depending on how 'dosfs' accesses the file you specified, it may work to give it the file name "\\.\g:" (according to win32.hlp, this is the syntax to access a whole drive, but some Windows C libraries sabotage and do not support this syntax). This is how I test my file system implementation on live data.
This is the equivalent of "/dev/hda1" etc. under Linux. You need admin rights, but if you can format your thumb drive, you probably already have them.
My mistake - I was editing and got a FAT16 comment mixed in with the FAT32 comment. FAT32 volumes cannot be smaller than 32MB, and FAT16 volumes must be smaller than 2GB. FAT32 volumes can be up to 2TB.
I agree that the on-disk format spec implies that larger volumes can be created, but Microsoft specifies that the limits on FAT32 are "32GB for all OS, 2TB for some OS". Look at KB154997 on support.microsoft.com. It is probably not a limitation of FAT32 per se, but a set of stacked limitations that would (say) make it impossible to boot Win98SE on a disk larger than 2TB.
Just under. The maximum number of clusters on a FAT16 volume is 65524 (not 65536). So the total data area is less than 2GB in all cases. Looking at the total volume size, the typical size of the reserved areas (boot stuff, FATs, root directory), will be typically be under
300KB (unless you've got a very large root directory - which you shouldn't, because many systems won't handle a FAT12/16 root directory with more than the standard 512 entries, or you have more than two copies of the FAT =96 again, that=92ll cause compatibility problems), and that, plus 65524*32K, still doesn't quite get you to 2GB.
Also, it's a pretty bad idea to hit the cluster limit exactly, since there's a ton of bad code out there with off-by-one or off-by-a-few errors in their FAT-type* detection code, so it's strongly recommended that you avoid formatting a volume with cluster counts closer than about +/-16 to the limits. Typically you'd go up or down one cluster size, and end up with twice or half as many clusters, and go from there.
*It's the number of clusters (and *only* the number of clusters) which determines the type of volume: Less than 4085 clusters (IOW 1-4084), it's FAT12, 4085-65524 it's FAT16, and 65525 or more it's FAT32. So the correct way to detect the volume type is to take the sector count, knock off the reserved, FAT and directory areas, divide by the number of sectors per cluster (all those values come from the BPB in the first sector of the volume), to get the cluster count, and compare it to those limits.
The systems using the file system have to keep track of file size. They can't measure things larger than 2GB in an int (which they need, in order to handle negative offsets in the software). Allowing files to grow above 2GB would lead to nasty undetectable errors when the file grew past 2GB.
[mail]: Chuck F (cbfalconer at maineline dot net)
While I won't say it doesn't (and I don't have an Me installation around to test), it does strike me as odd - first there are a number of places 32 bit sector numbers float around Win9x, and while some of the interfaces (for example *some* of the DCB structures) have provisions for longer sector numbers, I'm not sure how much actually treats those pairs of ULONGs and 64 bit numbers (rather than just filling in the low part). Then there's the issue of where you'd store the longer sector count in the BPB (presumably at the end, if both the
16 and 32 bit sector count fields are zero), and then there's the issue of why this would be worth it for only a four fold increase in storage.
And IIRC, WinMe never supported 48 bit LBA, so any non-SCSI physical disks would have to have been limited to 128GB.
Further, we're talking about an OS that only shipped between 2001 and
2003, and even extended support has been gone for a couple of years now. What would have been to motivation to support volumes that size? In 2003, you'd have needed to build an array of 17 120GB* drives to get to the 2TB limit. On a machine running Me?!
Could MS have gone to the trouble? Sure, but why... And if they had done it, why not allow Win2K, XP or Vista to mount such a volume? Heck - it would have made it impossible to upgrade such a machine to Win2K or XP. Of course NT never actually supported FAT32 with MS drivers (there was at least one third party drive that allowed you to mount a FAT32 volume on NT, and then FAT32 support was added by MS to Win2K), so there's precedent.
There is certainly some (OK, minimal now, but expected to grow) pressure from the embedded world to support a larger volume with a nice simple FS like FAT32, but then it would make sense to allow cluster numbers above 2**28 too. You could get to 128TB before needing major surgery on the format. And it would still leave you with a 4GB file size limitation. Of course MS is pushing (sort-of) exFAT instead, and the rational for such a format is considerably reduced if MS isn=92t going to ship support for it in Windows.
*I *think* you could get 120GB drives at the end of '03...