Subject: Re: Simplest (practical) file system?

From: "Dwight K. Elvey" <[email-masked]>
Date: Mon Jul 28 12:21:00 2003

>From: [email-masked]
>
>It was thus said that the Great Bob Shannon once stated:
>> 
---snip---
>
>  It also depends upon the size of the disk you are going to use---up to a
>few meg in size the MS-DOS FAT system (12 or 16 bit variants) will probably
>be the best bet---well documented with the ability for interoperability
>between most systems.
>
>  -spc (my two bits worth ... )
>

Hi Bob
 If you absolutely must start with a FAT system I think that
you should use a DOS like FAT. This makes things easy to
move from machine to machine. The 12 bit FAT is a little clumsy
so I'd suggest the 16 bit as the easier to deal with.
Dwight

---

From: Fred Cisin <[email-masked]>
Date: Mon Jul 28 12:52:01 2003

> so I'd suggest the 16 bit as the easier to deal with.

FAT16 is limited to 4G

But DOS and Win9x limits it to 2147483647 (NTx permits 4G).
The 2G limitation is due to the use of signed long ints in places that
should have an UNSIGNED long int.  Because of that, it can have files with
a NEGATIVE size!

One of my hard drives was getting crowded; I was down to less than a meg
of free space.  So, I stepped on the directory of a floppy, and created
a file that reported a size of -2147483648.  Surely, if I copied a file
with that much negative size to the drive, it would give me more free
space!   But it was unable to do the COPY.

---

From: ben franchuk <[email-masked]>
Date: Mon Jul 28 13:08:49 2003

> should have an UNSIGNED long int.  Because of that, it can have files with

Now is a good time to back up your system. AND MAKE SURE THE BACK UP WORKS!

---

From: "Patrick Rigney" <[email-masked]>
Date: Mon Jul 28 13:11:00 2003

> so I'd suggest the 16 bit as the easier to deal with.

I'll second that!  Although it's just a little shifting, I'm a lazy
programmer type and debugging allocation problems in your implementation
will be easier when everything is aligned on byte/word boundaries. :-)

Patrick

---

From: Paul Williams <[email-masked]>
Date: Mon Jul 28 13:13:01 2003

> space!   But it was unable to do the COPY.

You should've used PKZIP. If your negative length file contained only 
nulls, they would compress very well, maybe down to -100 bytes or so. If 
you add on the zip header information, you'd end up with a zip file with 
a very small positive length (call it 200 bytes). You copy this 200-byte 
file to your hard disk and unzip it to recreate the original -2GB file.

I think there are only two problems with this:

1. You won't gain anything if you're running with compression on your 
hard disk.

2. My glass is empty.

- Paul

---

From: "Patrick Rigney" <[email-masked]>
Date: Mon Jul 28 13:15:00 2003

> should have an UNSIGNED long int.  Because of that, it can have files with

Fred, I think another reason for this limit is that DOS only allows the
allocation unit (cluster) size be an even power of two.  That leaves out a
lot of possible values.  If Bob is willing to "forgive" DOS compatibility,
he could allow any allocation unit size that fits in a byte (so 255
theoretically, but he could also choose a 16- or 32-bit factor), allowing
for a much higher limit.  --Patrick