🚀 go-pugleaf

Aaron <chaaron@lave.net> wrote in message news:7pu7gj$7pn$1@mochi.lava.net...
> Tom MacIntyre wrote

>> Hyper, a good post, and the only scenario that I would
>> add is that fragmentation also occurs as files (data, text)
>> grow in size, past increments of the cluster size, where
>> the next cluster is no longer available. This type of event
>> is more likely on a FAT32 drive with its smaller clusters,
>> if there are many smaller data/text files being generated.

Wota pity that particular scenario wasnt even being discussed.

What was being discussed was the boot drive, using
FAT32, with either a single partition for the whole
drive, or a multiple paritions. BOTH were using FAT32.

> Great point Tom.

Nope, just another complete missing of the point of what was being discussed.

> I had thought to explain that fragmentation happens this way too, but
> found that Rod can't handle the mental imaging of files getting larger.

Pathetic really. I've been doing it since before
you were born boy. Including using an OS that
only ever wrote contiguous files for just that reason.

> Never thought to correlate it to the smaller cluster of FAT32.

Completely pointless when the alternate scenarious were BOTH Fat32.

> Of course more fragmentation would occur
> with a cluster size of 4KB instead of 16KB.

Aint gunna happen when using multiple partitions
or one partition WITH A FAT32 DRIVE.

> As you add to a report or database, the
> file will be fragmented all over the drive.

Complete tripe. And YOU claimed that it would all end up on the front
of the drive with the free space all down the back of the drive too. Wrong.

> Actually, I have been thinking it would be nice to be able to reserve
> a certain amount of space at the end of a file to prevent this.

And that is precisely what happens with a decent database
system. The file system cluster size is completely separated
from what the database system does about extending the file.

So your claim higher up is just plain wrong. As usual.

> If each document file were to tag the next few clusters when it is saved,
> and those tagged clusters would be preserved even after the drive is
> defragged, then the file could have room to grow without fragmenting.

That happens to some extent too. Not 'tagged', just that the
file doesnt increment by one cluster at a time in normal use.

> Maybe a check box available for certain file types
> or programs, such as *.doc files, or the MS Word
> program.  Same with database files and programs.

Much better looked after by the app, and thats what happens.

> But of course it isn't a big deal for me, as I only have to defrag
> one drive usually anyway, where I keep my documents
> and databases and files that I download off the web.

And any decent defragger that doesnt mindless move around
static files, will do just as well with a single partition too. The static
files just stay at the front of the drive and the stuff that changes
ends up at the boundary between the used and free space.