Sample DOSFS disk image file for testing

Hi Everybody-

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?)

Thanks,

JJS

Reply to
John Speth
Loading thread data ...

a
t

FS

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.

Reply to
robertwessel2

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.

Reply to
larwe

Um, sorry if I'm missing something, but why "less than 2GB" ? Isn't FAT32 good for many orders more than 2GB ? Thanks, Best Regards, Dave

Reply to
drn

(I'm the OP)

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?

JJS

Reply to
John Speth

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.

root directory:

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

Image file is at:

formatting link

Michael

Reply to
msg

Thanks. That's exactly what I need. The

formatting link
server is down or busy now. I'll try again later.

JJS

Reply to
John Speth

OSFS

OSFS

Thanks, Lewin. That's exactly what I needed.

JJS

Reply to
johnspeth

Sorry, the URL was on the internal domain, it should be:

formatting link

Michael

Reply to
msg

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.

Stefan

Reply to
Stefan Reuther

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.

Reply to
robertwessel2

Um, can't FAT16 go to 2GB ?

Reply to
drn

Why 2 TB ? 28 bit FAT x 32k cluster = 8 TB.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

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.

Reply to
larwe

Probably because 2TB = 512B sector x 32 bit sector count.

It seems like FAT32 is the most compatible filesystem despite of all imperfections.

BTW, I was surprised to find out how big is a file system overhead compared to the raw disk speed.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

There's a 32 bit sector count field in the BPB (at +32). If that got patched, I don't know of anything that would prevent an 8TB volume.

Reply to
robertwessel2

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.
Reply to
robertwessel2

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) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

Apparently Windows Me (blerk) can be coerced into using these big volumes. Of course, WHY is another question.......

Reply to
larwe

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...
Reply to
robertwessel2

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.