Will a new harddrive work witn win98SE?

98 Guy wrote:
dadiOH wrote:

That's what 98 was illustrating, many 1 to 2 kb files, each taking
16 kb's worth of storage Each cluser is the last cluster in the
file because the files are only 1 to 2kb.

Each would use one cluster. The smallest cluster is 4KB, not 16KB.

Why can't you follow this thread properly?

I dunno, why can't you get partition size vs. cluster size correct?

You said it is...

64 - 128 gb volume size - 32kb cluster size
32 - 64 gb volume size - 16kb cluster size
16 - 32 gb volume size - 8kb cluster size
8 - 16 gb volume size - 4kb cluster size

Microsoft says it is...

Partition size Cluster size
-------------------------------------
512 MB to 8,191 MB 4 KB
8,192 MB to 16,383 MB 8 KB
16,384 MB to 32,767 MB 16 KB
Larger than 32,768 MB 32 KB

My money - and experience - is on MS.

--

dadiOH
____________________________

dadiOH's dandies v3.06...
....a help file of info about MP3s, recording from
LP/cassette and tips & tricks on this and that.
Get it at http://mysite.verizon.net/xico

Jeff Richards wrote:

Jeff, read my last post and you'll see what I mean.

What you are discussing is not relevant to my post.

What did you mean when you said that FAT32 "does not scale well" ?

Were you refering to cluster size?

Your claim was 'they have never explained why they [restricted
the size of the FAT32 partitions that could be created in XP
and W2K]" and I gave you the stated, published, reason.

You said:

"MS has made it quite clear why they restricted W2K and
XP users to creating partitions no larger than 32Gb in
FAT32 - it's because FAT32 does not scale well and does
not perform as well as NTFS for large partitions."

Where did MS say that?

Can you provide a reference?

And again, what is meant by "FAT32 does not scale well", and what
performance scale or parameter are you refering to when you say that
FAT32 "does not perform as well as NTFS for large partitions" ?

Presumably, since you are directly quoting Microsoft, you can easily
find where Microsoft says those things and provide them here in your
next reply.

Whether or not you accept that their reason is supportable or
realistic or whatever doesn't matter -

What matters first is to SEE Microsoft's own statements.

you asked for their reason (which you claimed was
not available) and I provided it.

All you did was to state two reasons that *you claim* to be Microsoft's
reasons.

Do you seriously think that I or anyone else reading this is supposed to
believe those are Microsoft's reasons just because you claim they are?

You can start an argument about whether NTFS is better or worse
than FAT32 if you want. I won't be part of that.

I know you won't. You have a vested interest to protect what you
believe to be Microsoft philosophy regarding the technology decisions
and the business decisions they make.

But I will point out that your claim the MS have never explained
why they imposed this restriction is simply wrong.

Then it should be easy to provide a URL where they state for themselves
why they did not want Win 2K/XP to have the ability to create FAT32
partitions larger than 32 gb.

Jeff Richards wrote:

Jeff, read my last post and you'll see what I mean.

What you are discussing is not relevant to my post.

What did you mean when you said that FAT32 "does not scale well" ?

Were you refering to cluster size?

Your claim was 'they have never explained why they [restricted
the size of the FAT32 partitions that could be created in XP
and W2K]" and I gave you the stated, published, reason.

You said:

"MS has made it quite clear why they restricted W2K and
XP users to creating partitions no larger than 32Gb in
FAT32 - it's because FAT32 does not scale well and does
not perform as well as NTFS for large partitions."

Where did MS say that?

Can you provide a reference?

And again, what is meant by "FAT32 does not scale well", and what
performance scale or parameter are you refering to when you say that
FAT32 "does not perform as well as NTFS for large partitions" ?

Presumably, since you are directly quoting Microsoft, you can easily
find where Microsoft says those things and provide them here in your
next reply.

Whether or not you accept that their reason is supportable or
realistic or whatever doesn't matter -

What matters first is to SEE Microsoft's own statements.

you asked for their reason (which you claimed was
not available) and I provided it.

All you did was to state two reasons that *you claim* to be Microsoft's
reasons.

Do you seriously think that I or anyone else reading this is supposed to
believe those are Microsoft's reasons just because you claim they are?

You can start an argument about whether NTFS is better or worse
than FAT32 if you want. I won't be part of that.

I know you won't. You have a vested interest to protect what you
believe to be Microsoft philosophy regarding the technology decisions
and the business decisions they make.

But I will point out that your claim the MS have never explained
why they imposed this restriction is simply wrong.

Then it should be easy to provide a URL where they state for themselves
why they did not want Win 2K/XP to have the ability to create FAT32
partitions larger than 32 gb.

MEB wrote:

You are just pulling those two reasons out of your ass as the
plausible explanations they might use if someone put a gun to
their head and forced them to explain why they did it.

Go back to those links we provided to you when you first want to
know about formatting, Fat, vFat/Fat32, and other formats and
reasons [from which you have now come to your own untested
results].

Again, you provide a non-answer to have the reader chase down
non-existent material.

Included in those linked materials were indications of WHY.

Here is a link on this topic:

http://support.microsoft.com/kb/184006

This is the fourth point from that document:

=================
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot
process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).
Including the FATs themselves, this works out, at the maximum of 32 KB
per cluster, to a volume size of 127.53 gigabytes (GB).
================

The above explanation is completely wrong in that both Windows 98 and
DOS scandisk can easily handle FAT32 volumes that exceed a FAT size of
16 mb which can be achieved by using third-party drive preparation tools
to create a volume with smaller-than-usual cluster size.

The next point from that document is also wrong:

================
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
================

If they are speaking about the use of Microsoft's own intrinsic
utilities and drive-formatting functions, then yes that is true. If
they are speaking in generalities about whether the FAT32 specification
can allow for a FAT that is larger than 16 mb (and if Win 98/Me/2K/XP
can correctly work with such a FAT32 volume) then the statement is
wrong.

Then we have the classic last point:

================
You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. (...) This behavior is by design. If you
need to create a volume larger than 32 GB, use the NTFS file system
instead.
================

A very terse, dry statement, conveying no reason why that "behavior" was
chosen.

MEB wrote:

You are just pulling those two reasons out of your ass as the
plausible explanations they might use if someone put a gun to
their head and forced them to explain why they did it.

Go back to those links we provided to you when you first want to
know about formatting, Fat, vFat/Fat32, and other formats and
reasons [from which you have now come to your own untested
results].

Again, you provide a non-answer to have the reader chase down
non-existent material.

Included in those linked materials were indications of WHY.

Here is a link on this topic:

http://support.microsoft.com/kb/184006

This is the fourth point from that document:

=================
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot
process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).
Including the FATs themselves, this works out, at the maximum of 32 KB
per cluster, to a volume size of 127.53 gigabytes (GB).
================

The above explanation is completely wrong in that both Windows 98 and
DOS scandisk can easily handle FAT32 volumes that exceed a FAT size of
16 mb which can be achieved by using third-party drive preparation tools
to create a volume with smaller-than-usual cluster size.

The next point from that document is also wrong:

================
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
================

If they are speaking about the use of Microsoft's own intrinsic
utilities and drive-formatting functions, then yes that is true. If
they are speaking in generalities about whether the FAT32 specification
can allow for a FAT that is larger than 16 mb (and if Win 98/Me/2K/XP
can correctly work with such a FAT32 volume) then the statement is
wrong.

Then we have the classic last point:

================
You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. (...) This behavior is by design. If you
need to create a volume larger than 32 GB, use the NTFS file system
instead.
================

A very terse, dry statement, conveying no reason why that "behavior" was
chosen.

On 08/05/2009 09:09 AM, 98 Guy wrote:
MEB wrote:

You are just pulling those two reasons out of your ass as the
plausible explanations they might use if someone put a gun to
their head and forced them to explain why they did it.
Go back to those links we provided to you when you first want to
know about formatting, Fat, vFat/Fat32, and other formats and
reasons [from which you have now come to your own untested
results].

Again, you provide a non-answer to have the reader chase down
non-existent material.

Yes, I expect readers to actually do their own research. I also ALWAYS
direct them to your openly ignorant ramblings when you engage in
discussions such as this.


Included in those linked materials were indications of WHY.

Here is a link on this topic:

http://support.microsoft.com/kb/184006

This is the fourth point from that document:

=================
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot
process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).
Including the FATs themselves, this works out, at the maximum of 32 KB
per cluster, to a volume size of 127.53 gigabytes (GB).
================

The above explanation is completely wrong in that both Windows 98 and
DOS scandisk can easily handle FAT32 volumes that exceed a FAT size of
16 mb which can be achieved by using third-party drive preparation tools
to create a volume with smaller-than-usual cluster size.

As usual, even though we have done THIS same style and type of
discussion over several years of your constant: misquotes; failure to
understand the importance of cumulative documentation; constantly wrong
impressions regarding materials which were presented to you beginning
some five years ago, and again four years ago, and again three years
ago, and again two years ago; while you consistently claim Microsoft,
while explaining its own *patented* file system has falsely stated its
system AND what its own tools support. Meanwhile, using your same
UNTESTED results; the tests being those which I have PERSONALLY and
specifically defined for you three or four times as necessary for you to
even begin to make further claims, and which you have refused to perform
and ignored.
Can the file system be manipulated by external/third party tools and
configured in a form which *Microsoft did NOT design* for the
file/storage system, yes... does that mean Microsoft lied about the
system.. NO.


The next point from that document is also wrong:

================
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
================

If they are speaking about the use of Microsoft's own intrinsic
utilities and drive-formatting functions, then yes that is true. If
they are speaking in generalities about whether the FAT32 specification
can allow for a FAT that is larger than 16 mb (and if Win 98/Me/2K/XP
can correctly work with such a FAT32 volume) then the statement is
wrong.

Once again you ignore Microsoft, the *OWNER* of the PATENTED
file/storage system. These styles and types of Microsoft's statements
are its own *DESIGN characteristics* [which it has modified over time].
Does it matter that third party applications can circumvent the design
characteristics,, no... what matters is that the system is NOT designed
to be used in that fashion for a specific reason; maximum storage safety
for the user of that PATENTED file/storage system.

The above statements are NOT wrong regarding the NTs because the
driver/function used within the NTs is *NOT* the same as used in DOS or
9X. There is another layer used PRIOR to the interpretive Fat driver.
Yet, once again, speaking out of your inability to understand that which
you CLAIM to understand, you ignore and dismiss the fundamental and
inherent principles involved in the systems and respective OSs.


Then we have the classic last point:

================
You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. (...) This behavior is by design. If you
need to create a volume larger than 32 GB, use the NTFS file system
instead.
================

A very terse, dry statement, conveying no reason why that "behavior" was
chosen.

The KEY to that is: "This behavior is by design."
*TRY* to use that limited mental ability of yours to determine what
that means, verses the other materials posted repeatedly here in this
group, and produced by Microsoft, and by others which HAVE done proper
testing, and most of which you have already been directed to over the
course of these years and discussions; to UNDERSTAND *WHY*, an operating
*system* [NT] that is designed around purported *ENHANCED filing system
SECURITY* and other supposed storage and accessing enhancements might be
*DESIGNED* to NOT use a filing system which provides **NONE**; moreover,
*WHY* Microsoft's recommendation is to use its NTFS system which *DOES*
provide this purported enhanced security among other extended
enhancements DESIGNED into the NTs.

When your done with lengthy dialog with yourself, *TRY* to figure out
why parties such as yourself spend large time periods and, in fact,
years discussing this IGNORANT insistence to use the Fat based system in
the NTs which defeats the purported security AND filing abilities of the
OS you are using; in these poorly thought out and clearly ignorant
ramblings which STILL fill discussion groups after years of thousands of
people explaining EVERY CONCEIVABLE aspect to the contrary of its usage.

--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______

On 08/05/2009 09:09 AM, 98 Guy wrote:
MEB wrote:

You are just pulling those two reasons out of your ass as the
plausible explanations they might use if someone put a gun to
their head and forced them to explain why they did it.
Go back to those links we provided to you when you first want to
know about formatting, Fat, vFat/Fat32, and other formats and
reasons [from which you have now come to your own untested
results].

Again, you provide a non-answer to have the reader chase down
non-existent material.

Yes, I expect readers to actually do their own research. I also ALWAYS
direct them to your openly ignorant ramblings when you engage in
discussions such as this.


Included in those linked materials were indications of WHY.

Here is a link on this topic:

http://support.microsoft.com/kb/184006

This is the fourth point from that document:

=================
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot
process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).
Including the FATs themselves, this works out, at the maximum of 32 KB
per cluster, to a volume size of 127.53 gigabytes (GB).
================

The above explanation is completely wrong in that both Windows 98 and
DOS scandisk can easily handle FAT32 volumes that exceed a FAT size of
16 mb which can be achieved by using third-party drive preparation tools
to create a volume with smaller-than-usual cluster size.

As usual, even though we have done THIS same style and type of
discussion over several years of your constant: misquotes; failure to
understand the importance of cumulative documentation; constantly wrong
impressions regarding materials which were presented to you beginning
some five years ago, and again four years ago, and again three years
ago, and again two years ago; while you consistently claim Microsoft,
while explaining its own *patented* file system has falsely stated its
system AND what its own tools support. Meanwhile, using your same
UNTESTED results; the tests being those which I have PERSONALLY and
specifically defined for you three or four times as necessary for you to
even begin to make further claims, and which you have refused to perform
and ignored.
Can the file system be manipulated by external/third party tools and
configured in a form which *Microsoft did NOT design* for the
file/storage system, yes... does that mean Microsoft lied about the
system.. NO.


The next point from that document is also wrong:

================
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
================

If they are speaking about the use of Microsoft's own intrinsic
utilities and drive-formatting functions, then yes that is true. If
they are speaking in generalities about whether the FAT32 specification
can allow for a FAT that is larger than 16 mb (and if Win 98/Me/2K/XP
can correctly work with such a FAT32 volume) then the statement is
wrong.

Once again you ignore Microsoft, the *OWNER* of the PATENTED
file/storage system. These styles and types of Microsoft's statements
are its own *DESIGN characteristics* [which it has modified over time].
Does it matter that third party applications can circumvent the design
characteristics,, no... what matters is that the system is NOT designed
to be used in that fashion for a specific reason; maximum storage safety
for the user of that PATENTED file/storage system.

The above statements are NOT wrong regarding the NTs because the
driver/function used within the NTs is *NOT* the same as used in DOS or
9X. There is another layer used PRIOR to the interpretive Fat driver.
Yet, once again, speaking out of your inability to understand that which
you CLAIM to understand, you ignore and dismiss the fundamental and
inherent principles involved in the systems and respective OSs.


Then we have the classic last point:

================
You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. (...) This behavior is by design. If you
need to create a volume larger than 32 GB, use the NTFS file system
instead.
================

A very terse, dry statement, conveying no reason why that "behavior" was
chosen.

The KEY to that is: "This behavior is by design."
*TRY* to use that limited mental ability of yours to determine what
that means, verses the other materials posted repeatedly here in this
group, and produced by Microsoft, and by others which HAVE done proper
testing, and most of which you have already been directed to over the
course of these years and discussions; to UNDERSTAND *WHY*, an operating
*system* [NT] that is designed around purported *ENHANCED filing system
SECURITY* and other supposed storage and accessing enhancements might be
*DESIGNED* to NOT use a filing system which provides **NONE**; moreover,
*WHY* Microsoft's recommendation is to use its NTFS system which *DOES*
provide this purported enhanced security among other extended
enhancements DESIGNED into the NTs.

When your done with lengthy dialog with yourself, *TRY* to figure out
why parties such as yourself spend large time periods and, in fact,
years discussing this IGNORANT insistence to use the Fat based system in
the NTs which defeats the purported security AND filing abilities of the
OS you are using; in these poorly thought out and clearly ignorant
ramblings which STILL fill discussion groups after years of thousands of
people explaining EVERY CONCEIVABLE aspect to the contrary of its usage.

--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______

"MEB" wrote in message
...
On 08/05/2009 09:09 AM, 98 Guy wrote:
MEB wrote:

You are just pulling those two reasons out of your ass as the
plausible explanations they might use if someone put a gun to
their head and forced them to explain why they did it.
Go back to those links we provided to you when you first want to
know about formatting, Fat, vFat/Fat32, and other formats and
reasons [from which you have now come to your own untested
results].

Again, you provide a non-answer to have the reader chase down
non-existent material.

Yes, I expect readers to actually do their own research. I also ALWAYS
direct them to your openly ignorant ramblings when you engage in
discussions such as this.


Included in those linked materials were indications of WHY.

Here is a link on this topic:

http://support.microsoft.com/kb/184006

This is the fourth point from that document:

=================
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot
process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).
Including the FATs themselves, this works out, at the maximum of 32 KB
per cluster, to a volume size of 127.53 gigabytes (GB).
================

The above explanation is completely wrong in that both Windows 98 and
DOS scandisk can easily handle FAT32 volumes that exceed a FAT size of
16 mb which can be achieved by using third-party drive preparation tools
to create a volume with smaller-than-usual cluster size.

As usual, even though we have done THIS same style and type of discussion
over several years of your constant: misquotes; failure to understand the
importance of cumulative documentation; constantly wrong impressions
regarding materials which were presented to you beginning some five years
ago, and again four years ago, and again three years ago, and again two
years ago; while you consistently claim Microsoft, while explaining its
own *patented* file system has falsely stated its system AND what its own
tools support. Meanwhile, using your same UNTESTED results; the tests
being those which I have PERSONALLY and specifically defined for you three
or four times as necessary for you to even begin to make further claims,
and which you have refused to perform and ignored.
Can the file system be manipulated by external/third party tools and
configured in a form which *Microsoft did NOT design* for the file/storage
system, yes... does that mean Microsoft lied about the system.. NO.


The next point from that document is also wrong:

================
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
================

If they are speaking about the use of Microsoft's own intrinsic
utilities and drive-formatting functions, then yes that is true. If
they are speaking in generalities about whether the FAT32 specification
can allow for a FAT that is larger than 16 mb (and if Win 98/Me/2K/XP
can correctly work with such a FAT32 volume) then the statement is
wrong.

Once again you ignore Microsoft, the *OWNER* of the PATENTED file/storage
system. These styles and types of Microsoft's statements are its own
*DESIGN characteristics* [which it has modified over time].
Does it matter that third party applications can circumvent the design
characteristics,, no... what matters is that the system is NOT designed to
be used in that fashion for a specific reason; maximum storage safety for
the user of that PATENTED file/storage system.

The above statements are NOT wrong regarding the NTs because the
driver/function used within the NTs is *NOT* the same as used in DOS or
9X. There is another layer used PRIOR to the interpretive Fat driver. Yet,
once again, speaking out of your inability to understand that which you
CLAIM to understand, you ignore and dismiss the fundamental and inherent
principles involved in the systems and respective OSs.


Then we have the classic last point:

================
You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. (...) This behavior is by design. If you
need to create a volume larger than 32 GB, use the NTFS file system
instead.
================

A very terse, dry statement, conveying no reason why that "behavior" was
chosen.

The KEY to that is: "This behavior is by design."
*TRY* to use that limited mental ability of yours to determine what that
means, verses the other materials posted repeatedly here in this group,
and produced by Microsoft, and by others which HAVE done proper testing,
and most of which you have already been directed to over the course of
these years and discussions; to UNDERSTAND *WHY*, an operating *system*
[NT] that is designed around purported *ENHANCED filing system SECURITY*
and other supposed storage and accessing enhancements might be *DESIGNED*
to NOT use a filing system which provides **NONE**; moreover, *WHY*
Microsoft's recommendation is to use its NTFS system which *DOES* provide
this purported enhanced security among other extended enhancements
DESIGNED into the NTs.

When your done with lengthy dialog with yourself, *TRY* to figure out why
parties such as yourself spend large time periods and, in fact, years
discussing this IGNORANT insistence to use the Fat based system in the NTs
which defeats the purported security AND filing abilities of the OS you
are using; in these poorly thought out and clearly ignorant ramblings
which STILL fill discussion groups after years of thousands of people
explaining EVERY CONCEIVABLE aspect to the contrary of its usage.

--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______



Found a reasonable explanation of the 32GB limitation for XP/2000's format
limitation for FAT32. Admittedly, its a bit vague as well. "many tasks on
a very large FAT32 file system become slow and inefficient"
http://en.wikipedia.org/wiki/File_Allocation_Table
--
Dave

"MEB" wrote in message
...
On 08/05/2009 09:09 AM, 98 Guy wrote:
MEB wrote:

You are just pulling those two reasons out of your ass as the
plausible explanations they might use if someone put a gun to
their head and forced them to explain why they did it.
Go back to those links we provided to you when you first want to
know about formatting, Fat, vFat/Fat32, and other formats and
reasons [from which you have now come to your own untested
results].

Again, you provide a non-answer to have the reader chase down
non-existent material.

Yes, I expect readers to actually do their own research. I also ALWAYS
direct them to your openly ignorant ramblings when you engage in
discussions such as this.


Included in those linked materials were indications of WHY.

Here is a link on this topic:

http://support.microsoft.com/kb/184006

This is the fourth point from that document:

=================
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory block
maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95
or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file
system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry
on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot
process the FAT on a volume using the FAT32 file system that defines
more than 4,177,920 clusters (including the two reserved clusters).
Including the FATs themselves, this works out, at the maximum of 32 KB
per cluster, to a volume size of 127.53 gigabytes (GB).
================

The above explanation is completely wrong in that both Windows 98 and
DOS scandisk can easily handle FAT32 volumes that exceed a FAT size of
16 mb which can be achieved by using third-party drive preparation tools
to create a volume with smaller-than-usual cluster size.

As usual, even though we have done THIS same style and type of discussion
over several years of your constant: misquotes; failure to understand the
importance of cumulative documentation; constantly wrong impressions
regarding materials which were presented to you beginning some five years
ago, and again four years ago, and again three years ago, and again two
years ago; while you consistently claim Microsoft, while explaining its
own *patented* file system has falsely stated its system AND what its own
tools support. Meanwhile, using your same UNTESTED results; the tests
being those which I have PERSONALLY and specifically defined for you three
or four times as necessary for you to even begin to make further claims,
and which you have refused to perform and ignored.
Can the file system be manipulated by external/third party tools and
configured in a form which *Microsoft did NOT design* for the file/storage
system, yes... does that mean Microsoft lied about the system.. NO.


The next point from that document is also wrong:

================
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
================

If they are speaking about the use of Microsoft's own intrinsic
utilities and drive-formatting functions, then yes that is true. If
they are speaking in generalities about whether the FAT32 specification
can allow for a FAT that is larger than 16 mb (and if Win 98/Me/2K/XP
can correctly work with such a FAT32 volume) then the statement is
wrong.

Once again you ignore Microsoft, the *OWNER* of the PATENTED file/storage
system. These styles and types of Microsoft's statements are its own
*DESIGN characteristics* [which it has modified over time].
Does it matter that third party applications can circumvent the design
characteristics,, no... what matters is that the system is NOT designed to
be used in that fashion for a specific reason; maximum storage safety for
the user of that PATENTED file/storage system.

The above statements are NOT wrong regarding the NTs because the
driver/function used within the NTs is *NOT* the same as used in DOS or
9X. There is another layer used PRIOR to the interpretive Fat driver. Yet,
once again, speaking out of your inability to understand that which you
CLAIM to understand, you ignore and dismiss the fundamental and inherent
principles involved in the systems and respective OSs.


Then we have the classic last point:

================
You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. (...) This behavior is by design. If you
need to create a volume larger than 32 GB, use the NTFS file system
instead.
================

A very terse, dry statement, conveying no reason why that "behavior" was
chosen.

The KEY to that is: "This behavior is by design."
*TRY* to use that limited mental ability of yours to determine what that
means, verses the other materials posted repeatedly here in this group,
and produced by Microsoft, and by others which HAVE done proper testing,
and most of which you have already been directed to over the course of
these years and discussions; to UNDERSTAND *WHY*, an operating *system*
[NT] that is designed around purported *ENHANCED filing system SECURITY*
and other supposed storage and accessing enhancements might be *DESIGNED*
to NOT use a filing system which provides **NONE**; moreover, *WHY*
Microsoft's recommendation is to use its NTFS system which *DOES* provide
this purported enhanced security among other extended enhancements
DESIGNED into the NTs.

When your done with lengthy dialog with yourself, *TRY* to figure out why
parties such as yourself spend large time periods and, in fact, years
discussing this IGNORANT insistence to use the Fat based system in the NTs
which defeats the purported security AND filing abilities of the OS you
are using; in these poorly thought out and clearly ignorant ramblings
which STILL fill discussion groups after years of thousands of people
explaining EVERY CONCEIVABLE aspect to the contrary of its usage.

--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______



Found a reasonable explanation of the 32GB limitation for XP/2000's format
limitation for FAT32. Admittedly, its a bit vague as well. "many tasks on
a very large FAT32 file system become slow and inefficient"
http://en.wikipedia.org/wiki/File_Allocation_Table
--
Dave

In message , mm
writes:
[]
I'm asking everyone: To remedy the problem of wasted space for small
files in big clusters, can't someone write a program that works like
Eudora or Agent and maybe all the other email and news programs.

That is, AGent bundles every article in my computer from this
newsgroup into one** big file, even though they coudl be made into
[]
Why can't a file handler program that is part of the OS do the same
thing with every little (and medium if they want, and even big) file
in a subdirectory? I would think even a 3rd party program could
intercept the file-save command and do the same thing.

As another has said, the disc compression utilities (discspace and
drivespace I think they're called) that came with some of the '9x family
did this: once they were loaded (as part of system/OS boot), drive C:
became (IIRR) drive H:, with an apparent drive C:, which was actually
one humongous file on the drive.

Maybe no one writes this because space is so cheap, but could it be
done???

The main disadvantage of it was the danger of losing everything - or, at
least, a lot - if that one file became corrupted. (The same applies, of
course, to the email and other similar applications [including the one I
use, Turnpike] that store everything in one or few files, though where
the mailbase/newsbase/whatever is small enough to be held in RAM and
only written to disc occasionally, the risk can be reduced somewhat). It
also slowed things down quite a bit, especially on a slower machine
(which unfortunately was likely to go with a smaller drive where the
thing was maybe thought necessary).
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
** http://www.soft255.demon.co.uk/G6JPG-PC/JPGminPC.htm for ludicrously
outdated thoughts on PCs. **

"You know, I'm beginning to think that the Right To Life movement in this
country believes that life officially begins when you agree with *them*."
- Dennis Miller