Re: Using Defrag from Win2000
thanatoid
news:ng90u419rf0ff4lf7...@4ax.com:
> Can I use the defragger from Windows 2000 on my Win98
> partition? Or vice versa..... use the Win98 defragger on
> the Win2000 partition? (All partitions are Fat32).
>
> Thanks
>
> LM
You should use the WinME version, available everywhere (it MAY
be the same one, I don't know, but I never heard the Win2000
version mentioned before),
But it really isn't THAT much better if at all.
PARTITIONS!
thanatoid
news:o4l0u4d1ht34a13tc...@4ax.com:
<SNIP>
> Actually I have been using the WinME defrag version for
> years. (for Win98)
>
> But the Win2000 version looks very different. I assume
> it's intended to defrag the NTFS drives.
Well then WHY are you interested? If you're gonna go NTFS you
mighty as well use the XP defragger unless you decide to install
Vista in which case you can use the Vista defragger. Now THERE's
an idea to keep everyone busy for a few years!
> I have Win98 on C:
> Win2000 on D:
> and also have E: F: G: H: I: plus Cdrom and Flash drives,
> ending with P:
Good.
98 Guy
Yes
> Or vice versa..... use the Win98 defragger on the Win2000
> partition? (All partitions are Fat32).
Yes.
Bill in Co.
> I would not use that POS under any circumstance. Using Win2K is one
> thing, but I would never format to NTFS, then I could not access the
> partition with dos. As others have said on this group, NTFS is the
> biggest downfall of all the NT type operating systems.
No one has said that except you. And just for the record, there ARE tools
available like NTFS4DOS, etc. You can Google it.
thanatoid
news:gsh1u4tge7j6f1vj8...@4ax.com:
> Where did I say I was going to use NTFS?
You implied some interest in its capability to handle NTFS here:
>> But the Win2000 version looks very different. I assume
>> it's intended to defrag the NTFS drives.
After saying whether you could use it with 98SE. I might have
misunderstood.
> I would not use that POS under any circumstance. Using
> Win2K is one thing, but I would never format to NTFS, then
> I could not access the partition with dos. As others have
> said on this group, NTFS is the biggest downfall of all the
> NT type operating systems.
Agreed. I don't know if "biggest", even if you use trusty FAT32
you're still fucked.
Bill in Co.
> really.
You mean, doesn't matter. But actually it does (see below).
> I heard there are tools for it, but I'd rather stick with
> Fat32 since the entire computer is that, and had to be for Win98. The
> last thing I need is having to learn to use more software when I
> already have dos and know how to use it.
Well, if I can do it, you can do it, and I'm sure I'm a lot older than you!
> I guess NTFS is a little faster,
That's not the advantage of using NTFS. The advantage is its robustness
and built-in file journaling for recovery. I've rarely seen a blue screen.
Granted, you give up some easy access in DOS, but even if you have that
(i.e. installing XP on a FAT32 partition), it's much more complicated for
restoration purposes than in is Win98SE. WinXP is much more sophisticated
and complex than Win98SE, so you have to give up some micromanaging of it.
And, once again, if you install WinXP on NTFS (as you should), you still
have access to other FAT32 volumes or partitions on the hard drive(s).
NTFS can see FAT32. If you insist on booting up in DOS to begin with, then
maybe this whole issue is a moot point. I haven't done that since the days
of Windows 3.1
> but I have no complaint about how Win2000 is running on here
> except it takes longer to load than 98.
>
> LM
A
Ninty8 Guy
> > Where did I say I was going to use NTFS?
> > of all the NT type operating systems.
>
> No one has said that except you.
Wrongo Bill.
I've said it many times, and posted solid material to back it up,
directing some of that material directly at you and your comments about
NTFS.
> And just for the record, there ARE tools
> available like NTFS4DOS, etc. You can Google it.
Why bother with that shit?
NTFS just isin't worth it.
Ninty8 Guy
> That's not the advantage of using NTFS.
NTFS has no advantage over FAT32 for the home or SOHO user. Only in
corporate, instutional or enterprise applications will the need for NTFS
emerge.
> The advantage is its robustness and built-in file
> journaling for recovery. I've rarely seen a blue screen.
NTFS journaling and blue-screen errors are unrelated to each other.
> And, once again, if you install WinXP on NTFS (as you should),
XP or 2K has no inherent need or reliance on NTFS.
Read the following Bill:
http://cquirke.blogspot.com/2006/01/bad-file-system-or-incompetent-os.html
http://cquirke.blogspot.com/2008/03/ntfs-vs-fatxx-data-recovery.html
http://cquirke.blogspot.com/2008/03/why-bad-sector-often-kills-you.html
http://cquirke.mvps.org/ntfs.htm
There are some blatant errors on those pages that make FAT32 look even
better.
After you've read that material, come back and discuss NTFS with us.
Bill in Co.
> Full-Quoter "Bill in Co." wrote:
>
>> That's not the advantage of using NTFS.
>
> NTFS has no advantage over FAT32 for the home or SOHO user. Only in
> corporate, instutional or enterprise applications will the need for NTFS
> emerge.
>
>> The advantage is its robustness and built-in file
>> journaling for recovery. I've rarely seen a blue screen.
>
> NTFS journaling and blue-screen errors are unrelated to each other.
Granted. But both are advantages.
>> And, once again, if you install WinXP on NTFS (as you should),
>
> XP or 2K has no inherent need or reliance on NTFS.
I never used the phrase "inherent need". Those are your words. If it were
"inherent", by definition, it would have to be.
> Read the following Bill:
>
> http://cquirke.blogspot.com/2006/01/bad-file-system-or-incompetent-os.html
>
> http://cquirke.blogspot.com/2008/03/ntfs-vs-fatxx-data-recovery.html
>
> http://cquirke.blogspot.com/2008/03/why-bad-sector-often-kills-you.html
>
> http://cquirke.mvps.org/ntfs.htm
>
> There are some blatant errors on those pages that make FAT32 look even
> better.
And what about the advantages of using NTFS? Or are you thinking, there
aren't any? (rhetorical comment :-). (and yes, I've used both)
> After you've read that material, come back and discuss NTFS with us.
See above. After you've read some other material on NTFS vs FAT32, I mean
(and not ONLY cquirke's. But I've also discussed this issue with cquirke
in the past in here, and agreed with him on a couple of advantages of FAT32
(mainly the DOS tools advantage), but probably before you were here.)
After *you've* done some more *complete* reading, and not just from one
source, come back and then discuss NTFS with us.
Ninety8 Guy
> > NTFS journaling and blue-screen errors are unrelated to each
> > other.
>
> Granted. But both are advantages.
Microsoft decided that NTFS needed journaling. Or more specifically,
that NT-based OS's need to perform journaling. Journalling isin't
necessary to read or write files to an NTFS file system. In theory,
win-9x could have performed journalling to FAT32 if they worked out the
appropriate strategy.
Is journaling an advantage? It depends on how often something goes
wrong (either in the OS, or the hardware). I think it's a waste of
time, given that hard drives, controllers, drivers and the overlying
operating systems are pretty robust for the past decade (win98
included).
> Granted. But both are advantages.
Not exactly sure what you meant by "both". We were talking about
journaling and blue-screen errors. I don't think you mean to say that
blue-scren errors are advantageous.
> > Read the following Bill:
> >
> > http://cquirke.blogspot.com/ ...
>
> And what about the advantages of using NTFS?
Microsoft had one main goal with NTFS: That only someone with admin
privledges should be able to get at most (if not all) of the files, and
that other users should have varying degrees of file access. The whole
concept of user rights had to be coded into the DNA of the file system.
Microsoft, as is their habbit, likes to come up with new ways to do old
things, if only to avoid patent wars. By doing that, it can mean they
come up with cludgy ways to do things. NTFS could be cludgy. Knowing
Microsoft, it probably is. But in any case it does work. But most
users don't need the added complexity of user rights, so they don't need
the very thing that sets NTFS apart from FAT32.
A secondary thing that NTFS does is handle shared files and multi-tasked
processes better than fat32. But again, you're far more likely to
encounter that in a file-server vs the home PC.
> Or are you thinking, there aren't any? (rhetorical comment :-).
Journaling doesn't preserve data, nor does it prevent an unintended
file-system event from happening. What journaling does it to make sure
the file system is "clean" after the event happens. And it also makes
sure that any partial data is completely lost after the event has
happened.
Remember that the file structure of NTFS is distributed. It is
therefore much more "delicate" than FAT32. That's why it tests each
file write for completeness in a journaling fashion. Fat32, on the
other hand, can't return the file system to the same state as existed
prior to an event. But what that means is that a partial write will
leave some clusters hanging or dis-connected from a file entry or a file
chain. The worst that can happen from that is you've just lost some
useable disk space. The best that can happen is that you can actually
recover usable date from those lost clusters.
The fact that you have lost clusters does not impact the integrity of
the file system to perform future file reads or writes. If a FAT32
drive accumulates lots of .chk files, then it's time for the owner to
look at the quality or condition of his hardware or power source, and
not point the finger at FAT32 itself.
Most of this is academic. Hard drives are much better at performing a
complete read or write in a safe and accurate manner today than they
were 10, 15, 20 years ago. Their error rate is much better. Their
caching is much better. Their ability to autonomously remap bad sectors
certainly levels the playing field between NTFS and FAT32.
> After you've read some other material on NTFS vs FAT32, I mean
> (and not ONLY cquirke's.
What do you recommend?
> But I've also discussed this issue with cquirke in the
> past in here, and agreed with him on a couple of advantages
> of FAT32 (mainly the DOS tools advantage), but probably
> before you were here.)
Do you disagree with him that:
- more tools are available for FAT32 vs NTFS for file
system maintanence, reconstruction and repair
- It takes more to go wrong with FAT32 data structures for
you to not be able to recover or reconstruct the drive
vs NTFS?
Do you disagree with me that:
- most users do not need the user-rights file-access
methods and strategies that NTFS makes possible
- journaling is a function more of the operating system
than the file system
- having unrestricted, command-line "DOS" file access is a
desirable ability for intermediate and power users?
- it's harder for malware (rootkits, etc) to "hide" their
presence on a FAT32 drive vs NTFS, and easier to remove.
> After *you've* done some more *complete* reading, and not
> just from one source, come back and then discuss NTFS
> with us.
Seeing that NTFS is proprietary, anyone looking for open-source
editorial or technical material for it is going to be hard pressed. I
invite you to provide some pointers to reading material that takes an
unbiased look at how it compares to FAT32.
If you have anything specific to say about cquirke's observations or
conclusions, then why don't you just voice them here?
thanatoid
news:eOwb#5uuJH...@TK2MSFTNGP03.phx.gbl:
> lett...@invalid.com wrote:
<SNIP>
>>>> Where did I say I was going to use NTFS?
>>>> I would not use that POS under any circumstance. Using
>>>> Win2K is one thing, but I would never format to NTFS,
>>>> then I could not access the partition with dos. As
>>>> others have said on this group, NTFS is the biggest
>>>> downfall of all the NT type operating systems.
<SNIP>
>> I heard there are tools for it, but I'd rather stick with
>> Fat32 since the entire computer is that, and had to be for
>> Win98. The last thing I need is having to learn to use
>> more software when I already have dos and know how to use
>> it.
>
> Well, if I can do it, you can do it, and I'm sure I'm a lot
> older than you!
>
>> I guess NTFS is a little faster,
>
> That's not the advantage of using NTFS. The advantage is
> its robustness and built-in file journaling for recovery.
It is well known that in case of a fatal crash, recovery of data
with NTFS is MUCH harder (some say practically impossible) with
NTFS. And let's face it, most people don't back up.
<SNIP>
Bill in Co.
> "Bill in Co." wrote:
>
>>> NTFS journaling and blue-screen errors are unrelated to each
>>> other.
>>
>> Granted. But both are advantages.
>
> Microsoft decided that NTFS needed journaling. Or more specifically,
> that NT-based OS's need to perform journaling. Journalling isin't
> necessary to read or write files to an NTFS file system. In theory,
> win-9x could have performed journalling to FAT32 if they worked out the
> appropriate strategy.
In theory? Big deal. I'm talking about what already exists - with NTFS.
> Is journaling an advantage? It depends on how often something goes
> wrong (either in the OS, or the hardware). I think it's a waste of
> time, given that hard drives, controllers, drivers and the overlying
> operating systems are pretty robust for the past decade (win98
> included).
You think it's a waste of time. And that's your opinion.
>> Granted. But both are advantages.
>
> Not exactly sure what you meant by "both". We were talking about
> journaling and blue-screen errors. I don't think you mean to say that
> blue-scren errors are advantageous.
>
>>> Read the following Bill:
>>>
>>> http://cquirke.blogspot.com/ ...
>>
>> And what about the advantages of using NTFS?
>
> Microsoft had one main goal with NTFS: That only someone with admin
> privledges should be able to get at most (if not all) of the files, and
> that other users should have varying degrees of file access. The whole
> concept of user rights had to be coded into the DNA of the file system.
> Microsoft, as is their habbit, likes to come up with new ways to do old
> things, if only to avoid patent wars. By doing that, it can mean they
> come up with cludgy ways to do things. NTFS could be cludgy. Knowing
> Microsoft, it probably is. But in any case it does work. But most
> users don't need the added complexity of user rights, so they don't need
> the very thing that sets NTFS apart from FAT32.
That's not the only thing, by a long shot.
> A secondary thing that NTFS does is handle shared files and multi-tasked
> processes better than fat32. But again, you're far more likely to
> encounter that in a file-server vs the home PC.
>
>> Or are you thinking, there aren't any? (rhetorical comment :-).
>
> Journaling doesn't preserve data, nor does it prevent an unintended
> file-system event from happening. What journaling does it to make sure
> the file system is "clean" after the event happens.
Which is good.
> And it also makes
> sure that any partial data is completely lost after the event has
> happened.
And pray tell exactly what is this "partial data" that you've been able to
successfully recover (and of real use) on FAT32, but not NTFS, volumes?
> Remember that the file structure of NTFS is distributed. It is
> therefore much more "delicate" than FAT32.
It's much more robust.
> That's why it tests each
> file write for completeness in a journaling fashion. Fat32, on the
> other hand, can't return the file system to the same state as existed
> prior to an event. But what that means is that a partial write will
> leave some clusters hanging or dis-connected from a file entry or a file
> chain.
Which are generally USELESS.
> The worst that can happen from that is you've just lost some
> useable disk space. The best that can happen is that you can actually
> recover usable date from those lost clusters.
Not usually. Most of those chk 0001 (etc) files are USELESS!
> The fact that you have lost clusters does not impact the integrity of
> the file system to perform future file reads or writes. If a FAT32
> drive accumulates lots of .chk files, then it's time for the owner to
> look at the quality or condition of his hardware or power source, and
> not point the finger at FAT32 itself.
Don't forget another big limitation of FAT32 is with the limited and wasted
cluser size limitations, and max allowable disk partition size due to that.
And, of course, no single file can EVER exceed 4 GB (and in some cases and
applications, only 2 GB).
> Most of this is academic.
Not really.
> Hard drives are much better at performing a
> complete read or write in a safe and accurate manner today than they
> were 10, 15, 20 years ago. Their error rate is much better. Their
> caching is much better. Their ability to autonomously remap bad sectors
> certainly levels the playing field between NTFS and FAT32.
>
>> After you've read some other material on NTFS vs FAT32, I mean
>> (and not ONLY cquirke's.
>
> What do you recommend?
I recommend you do a good Google search, as there are LOTS of articles
comparing and contrasting the relative advantages and disadvantages of NTFS
vs FAT.
>> But I've also discussed this issue with cquirke in the
>> past in here, and agreed with him on a couple of advantages
>> of FAT32 (mainly the DOS tools advantage), but probably
>> before you were here.)
>
> Do you disagree with him that:
>
> - more tools are available for FAT32 vs NTFS for file
> system maintanence, reconstruction and repair
Probably don't disagree. And how often have you had the need to really use
them? Do you have any extended experience using NTFS (snd WinXP) - over an
extended period of time? And if so, how often have you had the need to
recover a severely damaged installation by actually needing such tools?
> - It takes more to go wrong with FAT32 data structures for
> you to not be able to recover or reconstruct the drive
> vs NTFS?
>
> Do you disagree with me that:
>
> - most users do not need the user-rights file-access
> methods and strategies that NTFS makes possible
I'd probably agree that many do not, but I don't know about MOST.
Actually, in most homes (which often have more than one user), I'd probably
disagree.
> - journaling is a function more of the operating system
> than the file system
I think both.
> - having unrestricted, command-line "DOS" file access is a
> desirable ability for intermediate and power users?
Would be nice in some instances. But then again, under Windows XP, I'm
not sure how much *practical use* it really has in practice, as WinXP is so
much more complex than Win98SE. Fortunately, it is much more robust, so
blue screens and the like are very rare, UNLIKE in Win98SE, from my
experiences, where they were at least occasional)
> - it's harder for malware (rootkits, etc) to "hide" their
> presence on a FAT32 drive vs NTFS, and easier to remove.
Haven't had any issues with this on either system (I have an older Win98SE
system too).
>> After *you've* done some more *complete* reading, and not
>> just from one source, come back and then discuss NTFS
>> with us.
>
> Seeing that NTFS is proprietary, anyone looking for open-source
> editorial or technical material for it is going to be hard pressed. I
> invite you to provide some pointers to reading material that takes an
> unbiased look at how it compares to FAT32.
See above. There is a lot of pretty technical material on it, if you do a
good and extensive search for it. But it is more complicated than FAT.
> If you have anything specific to say about cquirke's observations or
> conclusions, then why don't you just voice them here?
I've already said I agreed with him on a couple of advantages of FAT32,
already mentioned.
Bill in Co.
How can you really hate it, if you've never even really used it? ("used
it" means just that - really using it, not just a weekend trial).
I like XP and Win98SE. Each has its own place, but Win9x is "running out
of room" (a lot of recent stuff won't install or run on it, anymore, etc).
> I only installed Win2K for the few programs that need the NT platform.
> I like 2K pretty well, and I have used it on my laptop for awhile, so
> I know it somewhat. I just never used a dual boot before, other than
> my laptop dual boots to dos.
>
> There is no higher version of Windows that I will ever use. My next
> OS will probably be Linux, that's if I ever see a need to upgrade any
> further, which I doubt at my age.
MEB
Since it was suggested to search for comparisons.... why not go the full
route,, search for ext2 and ext3 file systems and compare, heck might as
well throw in HFS as well.
--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______
"Bill in Co." <not_rea...@earthlink.net> wrote in message
news:%23AIRyzz...@TK2MSFTNGP05.phx.gbl...
Bill in Co.
> On Sun, 12 Apr 2009 13:07:11 -0600, "Bill in Co."
> <not_rea...@earthlink.net> wrote:
>>>>
>>>
>>> I have no intention of using XP. I hate it !!!
>>
>> How can you really hate it, if you've never even really used it? ("used
>> it" means just that - really using it, not just a weekend trial).
>>
>
But THAT is EASY to get rid of - and to make it look like a Win98SE desktop.
That's almost the FIRST thing I did when I got XP! IOW, got rid of that
ugly, conglomerated, Start Menu, and made it the "Classic Start Menu", just
like the one in Win98SE. And that option is right there in XP.
> was/is a bloated POS that takes the user away from the computer
> because the user has no control of it.
More bloated than Win98SE, that is true. But - NOTHING like Vista!
> Then I saw what it did to a
> friend of mine, it ate every bit of data,
I'd probably blame it on the user. And apparently he didn't have any
backups. No matter WHAT system you use, you NEED a good backup.
> although I blame much of
> that on the NTFS because I tried to help them get the data using dos
> and found nothing could be done from dos. I tried their so called
> repair cd, it refused to do anything.
> This person spent $1200 on this computer less than 2 years prior. A
> local computer store wanted $500 to fix it. I offered to install 98
> on it, but they just bought another computer, this time with Vista (I
> wished them luck with that beast).
We can agree on Vista. Thanks, but NO thanks. Now THERE is real bloat!
> Anyhow, they sold the original
> computer to someone else I know for $50. This guy is a real computer
> whiz. He said that xp was so badly screwed up, he had to toss the
> harddrive and replace it. The rest of the computer was good. He even
> tried a low level format and could not get it to work.
>
> While the owner is at fault for not backing up,
EXACTLY!!!
> I have to say I still
> have data on my compouter from when Dos or Win3.x was all there was.
> I have never has a OS completely devour itself. I've even dealt with
> hard drive failures and still could retrieve most of the data from
> dos.
Which could also possibly be retrieved with some good third party tools in
XP (on NTFS), IF needbe. But with a backup, it's a moot point.
> I will admit that NTFS format is worse than XP itself, but XP is
> still a bloated POS which takes the user away. NO THANKS !!!
You do have to give up some micromanaging when you leave Win9x -that is
true.
But in its place, you get a much more stable system, one MUCH less prone to
catastrophes and blue screens. It truly IS more stable, and more robust.
Part of that is no doubt due to leaving the direct access DOS legacy stuff
behind, and part to using NTFS, and part is just due to it being a more
advanced OS.
> Win2K still allows me to set it up the way I like it, dont have all
> that bloated crap, and in many ways is similar to 98. That I can live
> with.
Win2K may be fine too. But there are many apps that won't run on either
Win2K or Win9x anymore. Heck, even most of the current Tax software
programs!!
Ninty8 Guy
> You do have to give up some micromanaging when you leave Win9x -
> that is true.
>
> But in its place, you get a much more stable system, one MUCH less
> prone to catastrophes and blue screens. It truly IS more stable,
> and more robust.
Bill, I don't know what hardware you've run win-98 on, but my thesis
regarding win-98 stability is that win-98 was originally spec'd to run
on systems that were just asking for trouble - chief among them being
the unrealistic minimum 16 mb of ram. I also say that first generation
AGP video card drivers and even first generation AGP hardware
implimentations (both motherboard and video card) were also faulty and
helped give win-98 a black eye. In my experience, it was even worse if
they were using non-intel based motherboards (ie AMD cpu).
Given that most "power" users moved on to win-2K and XP early on, they
left the win-98 world with only that first year or two of win-98
experience on that early primative hardware. But it was those
impressions that stuck with them as they went from 2K to 2K3 and XP, and
those same early impressions of win-98 stuck with the technology press
at large. Those of us that kept installing win-98 on better and newer
hardware saw fewer operating issues over time.
And it happened relatively quickly. If you installed win-98se on
hardware that was current by mid-2004 (Intel P4 2.5 ghz, 512 mb ram,
Nvidia 5xxx or 6xxx AGP 8-x card, CD/DVD burner) you had a pretty solid
platform that was compatible with all software at the time.
My experience with Win-98 on P3 and P4-based motherboards with 256 to
512 mb of ram and Nvidia AGP graphics cards is that it's very stable for
a home or even SOHO situation. We still run win-98 on about a dozen
office computers in a small business situation, with our most
sophisticated network app being a some-what expensive accounting package
known as AccPac, but we have other network apps as well (Parts & Vendors
and Jana Contact). I'm able to work with scanned bit-image files that
are several hundred mb in size with CorelDraw 9.
I will agree that most developers will say that because win-9x runs
everything in ring-0 mode, that 9x can't isolate user/application memory
space from OS memory space, and hence a bad app can run amok and mess up
the OS to the point of system lockup or blue-screen error, but most
users are not code developers so that is rarely an issue. A badly
behaved app can bring a win-9x system down far more easily than an
NT-based system, but then I ask what are you doing running a bad app in
the first place?
Beyond a badly behaved app, win-9x's other so-called limitations
(various heaps that are limited to 64kb in size) rarely come up as a
true operating limitation.
> Part of that is no doubt due to leaving the direct access DOS
> legacy stuff behind,
Not sure I understand what you're saying there.
> and part to using NTFS
No. If win-9x had NTFS operability it wouldn't affect it's stability
(real or perceived) at all. Why do you keep raising the file system as
being a factor in OS "stability" ? The two are not related.
It's sortof like saying "if my digital camera used NTFS on it's internal
memory card instead of FAT32, then it would take better pictures".
> and part is just due to it being a more advanced OS.
NT is a more complicated OS. I don't consider it more advanced. Down
at their core, Vista and XP have really not evolved much beyond the
concepts that were put into practice with NT4. But the new desktop
motif that Microsoft comes up with with each new OS throws a lot of
people I guess.
Bill in Co.
Mine was a Dell 4100 desktop (800 MHz), circa 2000 or 2001, as I recall. I
got it up to 512 MB RAM, the max (which was more than enough). No Nvidia
or other fancy stuff. :-)
> My experience with Win-98 on P3 and P4-based motherboards with 256 to
> 512 mb of ram and Nvidia AGP graphics cards is that it's very stable for
> a home or even SOHO situation. We still run win-98 on about a dozen
> office computers in a small business situation, with our most
> sophisticated network app being a some-what expensive accounting package
> known as AccPac, but we have other network apps as well (Parts & Vendors
> and Jana Contact). I'm able to work with scanned bit-image files that
> are several hundred mb in size with CorelDraw 9.
>
> I will agree that most developers will say that because win-9x runs
> everything in ring-0 mode, that 9x can't isolate user/application memory
> space from OS memory space, and hence a bad app can run amok and mess up
> the OS to the point of system lockup or blue-screen error, but most
> users are not code developers so that is rarely an issue. A badly
> behaved app can bring a win-9x system down far more easily than an
> NT-based system, but then I ask what are you doing running a bad app in
> the first place?
Well, I have run an assortment of pretty good and sometimes specialized
software and shareware, and not just the Big Boys stuff (like Office), much
of it dedicated to audio restoration work, etc. When you have a wide
assortment of software authors you're bound to encounter some glitches.
> Beyond a badly behaved app, win-9x's other so-called limitations
> (various heaps that are limited to 64kb in size) rarely come up as a
> true operating limitation.
That 64K heap limitation was another one that occasionally was a problem
(granted, not all that often). But you were made aware of it, on occasion.
:-)
>> Part of that is no doubt due to leaving the direct access DOS
>> legacy stuff behind,
>
> Not sure I understand what you're saying there.
WindowsXP normally blocks direct hardware access, unlike DOS and Win9x.
Hence the chance apps can go astray is mitigated (due to bad code or
whatever).
>> and part to using NTFS
>
> No. If win-9x had NTFS operability it wouldn't affect it's stability
> (real or perceived) at all. Why do you keep raising the file system as
> being a factor in OS "stability" ? The two are not related.
>
> It's sortof like saying "if my digital camera used NTFS on it's internal
> memory card instead of FAT32, then it would take better pictures".
The file system itself is more advanced, and as such, has the potential to
give the OS (XP or NT) more stability or built-in file recoverability, as I
see it, like due to the journaling. I could be mistaken, but thats the way
I think of it.
>> and part is just due to it being a more advanced OS.
>
> NT is a more complicated OS. I don't consider it more advanced.
I do, and almost by definition.
You honestly don't believe NTFS is more advanced than FAT32? It's sorta
like saying you don't consider FAT32 any more advanced than FAT16 (but the
comparison isn't really in the same ballpark, by any means).
MEB
will find it crashing quite a bit more than you may think, if not setup the
logging abilities.
What makes users THINK it is more stable is that it doesn't take the system
down when crashing, it just stops and re-start the crashed service... if it
happens to be a file handling service or using it, those files CAN still be
lost regardless of supposed journaling and other in NTFS. Take out a good
portion of that file handling [file and memory or file and HAL] with a major
crash {which you may not even notice} and you may end up with unrecoverable
files due to the techniques used within NTFS.
--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______
"Bill in Co." <not_rea...@earthlink.net> wrote in message
news:%23BQT6hG...@TK2MSFTNGP05.phx.gbl...
Ninety8 Guy
> > If you installed win-98se on hardware that was current by mid-
> > 2004 (Intel P4 2.5 ghz, 512 mb ram, Nvidia 5xxx or 6xxx AGP 8-x
> > card, CD/DVD burner) you had a pretty solid platform that was
> > compatible with all software at the time.
>
> Mine was a Dell 4100 desktop (800 MHz), circa 2000 or 2001,
> as I recall. I got it up to 512 MB RAM, the max (which was
> more than enough). No Nvidia or other fancy stuff. :-)
The Dell 4100 seems to date to Q4 2000 as far as availability goes. It
came with 128 mb ram and Windows ME. NVidia GeForce2 AGP-4x graphics
card with 32 mb.
That vintage hardware does not qualify for what I consider to be a
stable platform for win-98.
I've run memtest on a lot of motherboards of that era with PC-133 memory
and see a lot of memory errors.
> Windows XP normally blocks direct hardware access, unlike DOS and
> Win9x. Hence the chance apps can go astray is mitigated (due to
> bad code or whatever).
NT-based OS's block direct access to hardware more for "security"
reasons than anything else.
Microsoft did a lot to NT to make it a competitive for the US gov't and
other institions that required a more "secure" desktop operating
platform (user rights management). If they didn't, unix-based
competition would have risen to more prominence back in the mid 1990's.
The truth is that not a lot of apps perform direct hardware access
anyways under win-9x.
> > Why do you keep raising the file system as being a factor in
> > OS "stability" ? The two are not related.
>
> The file system itself is more advanced, and as such, has the
> potential to give the OS (XP or NT) more stability or built-in
> file recoverability, as I see it, like due to the journaling.
What-ever instability you saw in win-98, I can tell you that FAT32 did
not cause it. I can tell you that a logically corrupted system file did
not cause it, because the odds of a logically corrupted system or
program file is extremely remote.
Journalling does not result in or increase file recoverability. System
files are never journaled because they're never written or over-written
or re-written. Journalling serves only to clean up any mess that's left
behind if a file-write operation is improperly terminated. System
files, apps, DLL's and other program-code files are rarely re-written
during normal use. Only temp data files, pagefile, user data files,
internet-sourced data caching are subject to file-writing. A lot of
that is garbage and not desirable anyways when the system goes down and
needs to be restarted. That's why .chk files are largely useless, and
that's also why the file system is still perfectly usable even if those
.chk files were never created and the lost clusters remained lost.
But you fault FAT32 and scandisk for giving you the option to save lost
fragments to chk files, and then complain and point the finger at those
files and say FAT32 sucks. But when 2K/XP has to perform it's own NTFS
chkdsk, and it automatically deletes it's version of orphaned fragments,
that's different - isin't it? Of course not. You don't see them on
NTFS because they're automatically deleted when an improper shutdown was
detected. NT doesn't give you the option to recover them.
> > NT is a more complicated OS. I don't consider it more
> > advanced.
>
> I do, and almost by definition.
> You honestly don't believe NTFS is more advanced than FAT32?
Is an 18-wheeler more advanced compared to a Honda Civic?
They're both vehicles. They can both transport people and things from A
to B. There are times when you really need an 18-wheeler to move
something. But most times the Honda Civic works just fine.
When you look at win-9x compared to (NT/2K/XP) they have a lot in
common. They're all 32-bit OS's that run in i86 protected mode. They
use practically the same registry hive structure. A lot of API files
are similar or exactly the same for both. And 2K/XP runs just fine
under FAT32.
> It's sorta like saying you don't consider FAT32 any more
> advanced than FAT16 (but the comparison isn't really in
> the same ballpark, by any means).
Technically speaking, the simplest approach is usually the more robust
and best-performing solution.
As a file system, FAT32 lacks the ability to allow file access based on
user credentials or rights. I'm speculating that that feature is made
possible by NTFS and not entirely contained or made possible by NT
itself in higher layers above the file system itself.
As a file system, FAT32 has a hard limit of max file size = 4gb.
As a file system, FAT32 max volume size is 2 tb and max hard drive size
is 8tb.
As a file system, FAT32 maintains 2 copies of it's FAT, so there is 100%
redundancy there.
As a file system, FAT32 can allocate cluster size as efficiently (or as
inefficiently) as NTFS. The observation that Microsoft has chosen to
scale cluster size up on FAT32 as volume-size goes up is an unnecessary
practice and I've proven it myself several times for both win-9x and XP.
As file systems go, both FAT32 and NTFS become logically "fragmented"
and microsoft-provided tools exist with both 9x and NT to defragment
their respective file systems.
NTFS hard limits for file size, volume size and drive size are much
larger than FAT32. Are those higher limits needed in the real world?
In my opinion, rarely for some, never for most.
I don't know what NTFS has for file-table redundancy. Based on what
I've read, it's file system is more distributed across the drive (for
performance reasons rather than logical reasons) and therefore has a
different vulnerability profile compared to FAT32's FAT tables.
NTFS is proprietary, and very few third-party tools exist to diagnose
and rebuild NTFS volumes.
FAT32 is well documented, and many third party tools exist that allow it
to be manipulated, defragged, checked for integrity, etc.
Finally, if you indeed did read CQuirke's commentary on file system
recovery, I don't know how you can defend NTFS from a recovery point of
view given it's more complex and distributed internal structures.
Many people believe that NTFS is light-years ahead of FAT32 largely
because it's 100% incompatible with win-9x, and also because so few
people really understand it (and they shouldn't, because Microsoft never
has properly documented it).
If the only fault you can point to regarding FAT32 is the collection of
.CHK files that *can* accumulate on the average win-98 system that's
been operating for 3, 5, 7 years straight without a re-build or
re-install, well that's a pretty lame fault.
Bill in Co.
> Sorry, but you continue to indicate XP is more stable,, check the logs,
> you
> will find it crashing quite a bit more than you may think, if not setup
> the
> logging abilities.
It has been more stable for me.
> What makes users THINK it is more stable is that it doesn't take the
> system
> down when crashing, it just stops and re-start the crashed service...
OR it just terminates the service. But also, I have a just-in-time
debugger to intercept any such (relatively rare) occurences (which I also
used on Win9x), called CrashDoctor (freebie), which proves useful at
intercepting them sometimes.
> if it happens to be a file handling service or using it, those files CAN
> still
> be lost regardless of supposed journaling and other in NTFS.
I'm not saying the files can never be lost. :-)
> Take out a good
> portion of that file handling [file and memory or file and HAL] with a
> major
> crash {which you may not even notice} and you may end up with
> unrecoverable
> files due to the techniques used within NTFS.
OR you may need to use some third party utilities to try and recover them.
Bill in Co.
> "Bill in Co." wrote:
>
>>> If you installed win-98se on hardware that was current by mid-
>>> 2004 (Intel P4 2.5 ghz, 512 mb ram, Nvidia 5xxx or 6xxx AGP 8-x
>>> card, CD/DVD burner) you had a pretty solid platform that was
>>> compatible with all software at the time.
>>
>> Mine was a Dell 4100 desktop (800 MHz), circa 2000 or 2001,
>> as I recall. I got it up to 512 MB RAM, the max (which was
>> more than enough). No Nvidia or other fancy stuff. :-)
>
> The Dell 4100 seems to date to Q4 2000 as far as availability goes. It
> came with 128 mb ram and Windows ME. NVidia GeForce2 AGP-4x
> graphics card with 32 mb.
>
> That vintage hardware does not qualify for what I consider to be a
> stable platform for win-98.
Well, I guess that is your opinion.
> I've run memtest on a lot of motherboards of that era with PC-133 memory
> and see a lot of memory errors.
I never ran into any memory errors, per se.
>> Windows XP normally blocks direct hardware access, unlike DOS and
>> Win9x. Hence the chance apps can go astray is mitigated (due to
>> bad code or whatever).
>
> NT-based OS's block direct access to hardware more for "security"
> reasons than anything else.
Not only that, but also to make it more stable from an applications
programming viewpoint. It's like putting up a protective shield. Plus
WinXP does a fair job of blocking unauthorized attempts at system file
replacements, unlike XP, where it's open season for any program.
> Microsoft did a lot to NT to make it a competitive for the US gov't and
> other institions that required a more "secure" desktop operating
> platform (user rights management). If they didn't, unix-based
> competition would have risen to more prominence back in the mid 1990's.
>
> The truth is that not a lot of apps perform direct hardware access
> anyways under win-9x.
But some do. Probably more so with games, but not only. Generally
anything that needs super fast video access, for example.
>>> Why do you keep raising the file system as being a factor in
>>> OS "stability" ? The two are not related.
>>
>> The file system itself is more advanced, and as such, has the
>> potential to give the OS (XP or NT) more stability or built-in
>> file recoverability, as I see it, like due to the journaling.
>
> What-ever instability you saw in win-98, I can tell you that FAT32 did
> not cause it.
I don't think I ever said "FAT causes instability", per se.
> I can tell you that a logically corrupted system file did
> not cause it, because the odds of a logically corrupted system or
> program file is extremely remote.
What, exactly, is a "logically corrupted file"?
> Journalling does not result in or increase file recoverability. System
> files are never journaled because they're never written or over-written
> or re-written. Journalling serves only to clean up any mess that's left
> behind if a file-write operation is improperly terminated.
And you don't think that's ever helpful or useful?
> System files, apps, DLL's and other program-code files are rarely
> re-written
> during normal use. Only temp data files, pagefile, user data files,
> internet-sourced data caching are subject to file-writing. A lot of
> that is garbage and not desirable anyways when the system goes down and
> needs to be restarted. That's why .chk files are largely useless, and
True enough.
> that's also why the file system is still perfectly usable even if those
> .chk files were never created and the lost clusters remained lost.
>
> But you fault FAT32 and scandisk for giving you the option to save lost
> fragments to chk files, and then complain and point the finger at those
> files and say FAT32 sucks. But when 2K/XP has to perform it's own NTFS
> chkdsk, and it automatically deletes it's version of orphaned fragments,
> that's different - isn't it? Of course not. You don't see them on
> NTFS because they're automatically deleted when an improper shutdown was
> detected. NT doesn't give you the option to recover them.
Well, it's not much of a "loss".
>>> NT is a more complicated OS. I don't consider it more
>>> advanced.
>>
>> I do, and almost by definition.
>> You honestly don't believe NTFS is more advanced than FAT32?
>
> Is an 18-wheeler more advanced compared to a Honda Civic?
>
> They're both vehicles. They can both transport people and things from A
> to B. There are times when you really need an 18-wheeler to move
> something. But most times the Honda Civic works just fine.
Not if I'm truckin' across country with a heavy load.
> When you look at win-9x compared to (NT/2K/XP) they have a lot in
> common. They're all 32-bit OS's that run in i86 protected mode. They
> use practically the same registry hive structure. A lot of API files
> are similar or exactly the same for both. And 2K/XP runs just fine
> under FAT32.
>
>> It's sorta like saying you don't consider FAT32 any more
>> advanced than FAT16 (but the comparison isn't really in
>> the same ballpark, by any means).
>
> Technically speaking, the simplest approach is usually the more robust
> and best-performing solution.
You didn't answer my question above.
Nor have you ever addressed the problem with the ridiculous and limited
cluster size limitations, and the max allowable partition sizes with FAT32
(more below).
Or that stupid 64K heap limitation, and occasionally running out of
resources (or coming close to the edge).
> As a file system, FAT32 lacks the ability to allow file access based on
> user credentials or rights. I'm speculating that that feature is made
> possible by NTFS and not entirely contained or made possible by NT
> itself in higher layers above the file system itself.
OK, for me that part as a home user isn't so important, but I'm sure it is
for some.
> As a file system, FAT32 has a hard limit of max file size = 4gb.
YUP. That is true.
> As a file system, FAT32 max volume size is 2 tb and max hard drive size
> is 8tb.
No, not true. I think the max partition size is MUCH less than that, due
to the 32 KB cluster size, and that you can only have 64K(?) (IIRC) total
number of clusters, due to the limits of a 16 bit integer used to hold those
values. So the max allowable partition size is much less than 2 TB as I
recall. I suppose I could look it up and/or calculate it but I'm too lazy.
:-)
> As a file system, FAT32 maintains 2 copies of it's FAT, so there is 100%
> redundancy there.
Between just those two copies, yes.
> As a file system, FAT32 can allocate cluster size as efficiently (or as
> inefficiently) as NTFS.
NO. If you have a large partition, you are FORCED to use a large cluster
size (like 32 KB is being used to store ANY single file, even a one byte
file). A 40 GB (for example) partition will REQUIRE 32 KB cluster sizes -
you can NOT override that, due to the reason I just mentioned. So any
single file being stored will take up at least 32 KB, no matter how small
the file actually is. Compare that to NTFS, with *4 KB* default cluster
sizes (regardless of how large the partition you want is, and that itself is
essentially unlimited), and get back to me on that (and the consequent
inefficiencies of FAT).
> The observation that Microsoft has chosen to
> scale cluster size up on FAT32 as volume-size goes up is an unnecessary
> practice and I've proven it myself several times for both win-9x and XP.
Nonsense. The large partitions are constrained by requiring larger cluster
sizes. For example, a 40 GB partition will require 32 KB cluster sizes,
and you are limited as to how many of those you can have (64K max total, as
I recall).
> As file systems go, both FAT32 and NTFS become logically "fragmented"
> and microsoft-provided tools exist with both 9x and NT to defragment
> their respective file systems.
True.
> NTFS hard limits for file size, volume size and drive size are much
> larger than FAT32. Are those higher limits needed in the real world?
> In my opinion, rarely for some, never for most.
Yes, see above. Today 250 GB and larger disks are common.
> I don't know what NTFS has for file-table redundancy. Based on what
> I've read, it's file system is more distributed across the drive (for
> performance reasons rather than logical reasons) and therefore has a
> different vulnerability profile compared to FAT32's FAT tables.
>
> NTFS is proprietary, and very few third-party tools exist to diagnose
> and rebuild NTFS volumes.
>
> FAT32 is well documented, and many third party tools exist that allow it
> to be manipulated, defragged, checked for integrity, etc.
>
> Finally, if you indeed did read CQuirke's commentary on file system
> recovery, I don't know how you can defend NTFS from a recovery point of
> view given it's more complex and distributed internal structures.
With third party tools. Admitedly it's more complex.
> Many people believe that NTFS is light-years ahead of FAT32 largely
> because it's 100% incompatible with win-9x, and also because so few
> people really understand it (and they shouldn't, because Microsoft never
> has properly documented it).
>
> If the only fault you can point to regarding FAT32 is the collection of
> .CHK files that *can* accumulate on the average win-98 system that's
> been operating for 3, 5, 7 years straight without a re-build or
> re-install, well that's a pretty lame fault.
Sorry, but that was NOT the only fault I pointed out. I mentioned SEVERAL
if you go back and reread what I had previously mentioned.
Ingeborg
> Can I use the defragger from Windows 2000 on my Win98 partition?
Yes, at a cost. W98 maintains a database of exe's and dll's which are
loaded often. (\Windows\Applog) W98 defrag uses this to put these files on
the faster places of the disk, speeding up the loadtimes.
W2000 defrag won't use this database.
> Or vice versa..... use the Win98 defragger on the Win2000 partition?
Yes, maybe at the same cost the other way around, but I don't know if W2000
has a similar mechanism,
Ninety8 Guy
> >> Mine was a Dell 4100 desktop (800 MHz)
> > That vintage hardware does not qualify for what I consider to
> > be a stable platform for win-98.
>
> Well, I guess that is your opinion.
And are you sure it came with win-98 vs ME?
> > NT-based OS's block direct access to hardware more for
> > "security" reasons than anything else.
>
> Not only that, but also to make it more stable from an
> applications programming viewpoint. It's like putting
> up a protective shield.
Because win-9x is not a multi-processing OS, it really didn't need to
"protect" the hardware from user apps. It's when you are switching
between processor contexts that you probably need to enforce hardware
access only to the OS itself.
> Plus WinXP does a fair job of blocking unauthorized attempts at
> system file replacements, unlike XP, where it's open season for
> any program. ^^^^^^^^^
I think you mean "unlike 98".
And again, if you're running a desirable or necessary program under 98
that must have access to the hardware, then if it works and the system
runs well then you've got no problems. If it doesn't work and the
system is unstable then it's up to the user to decide the pro's and
con's of continuing to use it vs seeking an alternative. If the
hardware is not part of the system (ie if it's some add-on piece of
hardware in an expansion slot that's not a video card) then there's
really no harm done by allowing a user app to directly access it because
it's likely the app is the only thing accessing it anyways.
> > The truth is that not a lot of apps perform direct hardware
> > access anyways under win-9x.
>
> But some do. Probably more so with games, but not only.
> Generally anything that needs super fast video access, for
> example.
Well I for one wouldn't cry over some pre-teen that can't properly
experience a particular game in win-98 because of problems caused by
direct hardware access.
> > What-ever instability you saw in win-98, I can tell you that
> > FAT32 did not cause it.
>
> I don't think I ever said "FAT causes instability", per se.
You're using a lot of per se's here.
You implied that because NTFS is more "advanced", that it helps give NT
a stability edge over 9x, because you equate "advanced" with "robust".
I said that as long as the file system is doing it's job, and it's
writing data accurately to files and retrieving them accurately for the
OS above it, then you can't point to file-system differences as factors
in measuring OS stability. Both NTFS and FAT32 correctly write and read
file data the vast majority of the time, and neither of them can perform
magic when sectors containing desired file data go bad.
> What, exactly, is a "logically corrupted file"?
A file that upon a read operation does not contain the data it's
supposed to because of logical file construction errors (cross-linked
clusters or trunkated chain). In other words, anything that was not
caused by a physical fault of the recording media or some other hardware
or electrical fault in or of the recording system.
> > Journalling does not result in or increase file recoverability.
> > System files are never journaled because they're never written
> > or over-written or re-written. Journalling serves only to
> > clean up any mess that's left behind if a file-write operation
> > is improperly terminated.
>
> And you don't think that's ever helpful or useful?
Actually, in some cases it's a detriment.
Case in point:
Our web server (running SP4) is powered via a large UPS. The batteries
in the UPS were at their expiry point (which I didn't realize) and were
not capable of running the server for more than 1 second during power
interruptions. A few months ago during a period of flaky power, I was
copying some web-log files from the server across the network to my
win-98 system. But I noticed later that when I went to retrieve the
same files from the server a day or two later, that they contained
substantially less, and sometimes no data for that day. My copies of
those log files that I had copied on those days actually contained more
data. It was because of this discovery that I figured out that the
system was shutting down unexpectedly, and the failure of the UPS
batteries was the reason. But NTFS journaling garanteed that because
IIS keeps it's log file open for the entire day, and only closes it just
after midnight the next day, that it reverted to it's journaled state
after being restarted, and hence we lost the majority of the data in
those log files for those days. I'd call that a situation where
journaling was un necessary and caused a loss of valuable data.
> > But you fault FAT32 and scandisk for giving you the option to
> > save lost fragments to chk files, and then complain and point
> > the finger at those files and say FAT32 sucks.
> > But when 2K/XP has to perform it's own NTFS chkdsk, and it
> > automatically deletes it's version of orphaned fragments,
> > that's different - isn't it? Of course not.
> > You don't see them on NTFS because they're automatically
> > deleted when an improper shutdown was detected. NT doesn't
> > give you the option to recover them.
>
> Well, it's not much of a "loss".
No it's not. But in my example above, a FAT32 file system would have
maintained all data that had been written to the file up to the point of
unexpected system shut-down. The roll-back to the journaled version of
the file was, in fact, detrimental.
But beyond that, I'm trying to get you to understand that the .chk files
you see in a FAT32 volume are not examples of any sort of failure or
"lack of robustness" of the file system. It's because the default
behavior of win-9x scandisk is to preserve lost clusters and file
fragments, while the default behavior of NTFS is to delete them. You
think that because you never see them on an NTFS file system, that they
never existed in the first place. That's where your perception is
wrong.
> >> You honestly don't believe NTFS is more advanced than FAT32?
> >
> > Is an 18-wheeler more advanced compared to a Honda Civic?
>
> Not if I'm truckin' across country with a heavy load.
And as a percentage of vehicles on the road, there are more cars than
trucks.
> You didn't answer my question above.
If I fail to answer questions, please restate them, so I know exactly
what the question is.
I believe you are referring to this question:
> >> You honestly don't believe NTFS is more advanced than FAT32?
You are trying to get me to say that NTFS is more advanced, so you can
say that I agree that NTFS is "better" or more desirable than FAT32.
There is no question that the NTFS specifications allow for a file
system that contains more meta-data than FAT32. I'm not totally
convinced that the journaling aspect is soley within the domain of the
file system, and not partially (or substantially) handled or performed
by the overlying NT operating system.
If something is "advanced", to me it means that it has features that are
useful to the user compared to the alternative. NTFS has features that
FAT32 does not. I do not believe those features are useful or
beneficial to (or even noticed by) the vast majority of users. Those
features, I believe, come at a cost, which should not happen with an
"advancement". The cost being the potential for a more complex,
time-consuming and expensive repair event should it fail. And certainly
the overhead of NTFS gives FAT32 a performance edge.
(I did some internet searching for this question, but it's a difficult
thing to find an answer to: If an NT-based OS like XP is installed on a
FAT32 volume, is it not possible for it to impliment a form of
journaling on it? Do we know for sure that such journaling _doesn't_
happen in that case?)
> Nor have you ever addressed the problem with the ridiculous and
> limited cluster size limitations, and the max allowable partition
> sizes with FAT32
> (more below).
Yes, see my response (below).
> Or that stupid 64K heap limitation, and occasionally running out
> of resources (or coming close to the edge).
The 64k heap is a limitation of win-98, and has nothing to do with FAT32
vs NTFS.
> > As a file system, FAT32 can allocate cluster size as efficiently
> > (or as inefficiently) as NTFS.
>
> NO. If you have a large partition, you are FORCED to use a large
> cluster size (like 32 KB is being used to store ANY single file,
> even a one byte file).
And here is where you are so wrong.
The specifications for FAT32 allow for complete freedom to choose the
cluster size irregardless of volume size.
Time and time again I've pointed this out.
Time and time again I've stated how I've formatted large hard drives
with FAT32 volumes with specific cluster sizes. Perhaps you go out of
your way not to read those posts, or you cover your eyes in disbelief.
I've formatted a 500 gb SATA drive as a single FAT32 volume, using 4kb
cluster size, resulting in 120 million clusters, and have sucessfully
installed and run win-98 on that drive.
I've formatted 250 gb and 80 gb drives as single FAT32 volumes using 4kb
cluster size and have successfully installed and run win-XP sp2 and sp3
on them.
You are confusing how Microsoft chose to scale cluster size on FAT32
compared to what the FAT32 specification actually allows.
Microsoft implimented this scaling in the native drive preparation /
formatting programs (format.com). The OS's themselves (9x, NT) do not
enforce these rules or require their adherence if you circumvent them
with third-party drive preparation tools.
Microsoft *CHOSE* to increase FAT32 cluster size with volume size. They
have offered some reasons for that, and I've shown how some of those
reasons are false. DOS scandisk, for one, can actually operate on the
large 500 gb volume with 120 million clusters, even though Microsoft
said the stated limit for scandisk is 4.17 million clusters. And while
the win-9x versions of scandisk and defrag are indeed limited to 4.17
million clusters, the win-me versions are not.
When it comes to any NT-based OS, those reasons simply do not exist.
There is certainly no reason why the FAT32 cluster count can't exceed 4
million for NT/2k/XP since there is no 16-bit file maintainence tools in
those OS's. Since Microsoft could not "handicap" the use of FAT-32 on
NT-based OS's, they decided to handicap the OS's themselves by taking
away their ability to create FAT32 volumes larger than 32 gb.
> > NTFS hard limits for file size, volume size and drive size are
> > much larger than FAT32. Are those higher limits needed in
> > the real world? In my opinion, rarely for some, never for most.
>
> Yes, see above. Today 250 GB and larger disks are common.
Again another confusion.
The FAT32 specification is not limited to hard drive size or volume size
until you reach or exceed 2.2 tb.
Now please understand the following points:
1) Win-9x comes with a protected-mode IDE driver, the file name
is ESDI_506.PDR. That file is not capable of correctly
handling a hard drive larger than 128 gb. That is not a
FAT32 issue. That is a sector-addressing issue within
that file.
2) If ESDI_506.PDR on win-9x is replaced with an alternative
driver, then the 128 gb drive-size limitation is removed
and drives larger than 128 gb can be attached to win-98
systems and fully utilized.
3) NT-based OS's were also limited to 128 gb drives for
the same reason as win-98 until XP-SP2 and 2K-sp4. With
those service packs, they became compatible with drives
larger than 128 gb (presumably up to the full spec allowed
by NTFS).
> > If the only fault you can point to regarding FAT32 is the
> > collection of .CHK files that *can* accumulate ...
>
> Sorry, but that was NOT the only fault I pointed out. I
> mentioned SEVERAL ...
Yes, you have.
And I've now given a rebuttal to those. What do you say in response?
Ninety8 Guy
> > Can I use the defragger from Windows 2000 on my Win98 partition?
>
> Yes, at a cost. W98 maintains a database of exe's and dll's which
> are loaded often. (\Windows\Applog) W98 defrag uses this to put
> these files on the faster places of the disk, speeding up the
> loadtimes. W2000 defrag won't use this database.
While that may be true, it's probably irrelevant today, given the huge
increase in hardware performance in today's hard drives and controllers
compared to when win-9x was originally designed.
Bill Blanton
> "Bill in Co." wrote:
>> >> You honestly don't believe NTFS is more advanced than FAT32?
> There is no question that the NTFS specifications allow for a file
> system that contains more meta-data than FAT32. I'm not totally
> convinced that the journaling aspect is soley within the domain of the
> file system, and not partially (or substantially) handled or performed
> by the overlying NT operating system.
It's both. The metadata $LogFile is kept on disk in the $MFT. The NTFS
driver checks the log when a volume is first accessed to see if any "undo" or
"redo" transaction information exists.
> If something is "advanced", to me it means that it has features that are
> useful to the user compared to the alternative. NTFS has features that
> FAT32 does not. I do not believe those features are useful or
> beneficial to (or even noticed by) the vast majority of users.
Assume you mean things like encryption, hard links,
sparse files, alternate data streams, etc.. probably not the
majority of users.
> Those
> features, I believe, come at a cost, which should not happen with an
> "advancement". The cost being the potential for a more complex,
> time-consuming and expensive repair event should it fail. And certainly
> the overhead of NTFS gives FAT32 a performance edge.
As far as FAT32 out-performing NTFS, that's not necessarily so. There's
a lot of talk about the hit journaling costs, but no mention of how files
are indexed. Finding and opening and writing files are a major part
of what an OS does. Nevermind user files.. Loading programs requires
10s of files to be found. Loading the OS requires 100s of files to be
found and opened.
NTFS's use of a b+tree algorithm to find files, blows away FAT's sequential
search. The larger the dir(s) and the more deeply nested, the moreso..
If you want to open a file that happens to be at the end of the dir,
FAT will have to search through every filename to find it. Nest that
"n-times" in possible subdirs at the end of parent dirs. (and again, not
just user files). On average it will have to search NumberOfDirEntries/2
for any files. Including Directories (technically files).
There's also the fact that small files may be kept wholly in the file's
data attribute field of the MFT. That itself may not be much
significance, but it does contribute to performance.
Fianlly, journaling only writes out what transactions took (are are to
take) place. It doesn't write out user data, and shouldn't be taht huge
a hit on performance.
FWIW, this site suggests FAT outperforms on small volumes..NTFS
outperforms on large volumes.
http://www.ntfs.com/ntfs_vs_fat.htm
From my understanding and personal experience, that sounds about right..
NTFS loses on small volumes because of overhead. FAT loses on large
volumes because of its inefficient search algorithm.
> (I did some internet searching for this question, but it's a difficult
> thing to find an answer to: If an NT-based OS like XP is installed on a
> FAT32 volume, is it not possible for it to impliment a form of
> journaling on it? Do we know for sure that such journaling _doesn't_
> happen in that case?)
AFAIK, no. There's no on-volume logfile or similar hidden structure.
Bill in Co.
> "Bill in Co." wrote:
>
>>>> Mine was a Dell 4100 desktop (800 MHz)
>
>>> That vintage hardware does not qualify for what I consider to
>>> be a stable platform for win-98.
>>
>> Well, I guess that is your opinion.
>
> And are you sure it came with win-98 vs ME?
Brand new with Win98SE, fortunately. (ok, I'll give ME a point for better
USB support, but that's it - but there was no way I wanted ME)
>>> NT-based OS's block direct access to hardware more for
>>> "security" reasons than anything else.
>>
>> Not only that, but also to make it more stable from an
>> applications programming viewpoint. It's like putting
>> up a protective shield.
>
> Because win-9x is not a multi-processing OS, it really didn't need to
> "protect" the hardware from user apps.
But that's not the only reason. Even if weren't, it would still be
desireable, no?
> It's when you are switching
> between processor contexts that you probably need to enforce hardware
> access only to the OS itself.
(But again, that's not the only reason).
>> Plus WinXP does a fair job of blocking unauthorized attempts at
>> system file replacements, unlike XP, where it's open season for
>> any program. ^^^^^^^^^
>
> I think you mean "unlike 98".
Right. :-)
> And again, if you're running a desirable or necessary program under 98
> that must have access to the hardware, then if it works and the system
> runs well then you've got no problems. If it doesn't work and the
> system is unstable then it's up to the user to decide the pro's and
> con's of continuing to use it vs seeking an alternative. If the
> hardware is not part of the system (ie if it's some add-on piece of
> hardware in an expansion slot that's not a video card) then there's
> really no harm done by allowing a user app to directly access it because
> it's likely the app is the only thing accessing it anyways.
>
>>> The truth is that not a lot of apps perform direct hardware
>>> access anyways under win-9x.
>>
>> But some do. Probably more so with games, but not only.
>> Generally anything that needs super fast video access, for
>> example.
>
> Well I for one wouldn't cry over some pre-teen that can't properly
> experience a particular game in win-98 because of problems caused by
> direct hardware access.
But - it wasn't only games.
>>> What-ever instability you saw in win-98, I can tell you that
>>> FAT32 did not cause it.
>>
>> I don't think I ever said "FAT causes instability", per se.
>
> You're using a lot of per se's here.
I'm trying to be explicit.
> You implied that because NTFS is more "advanced", that it helps give NT
> a stability edge over 9x, because you equate "advanced" with "robust".
*In conjunction with* the operating system, XP. If one could somehow
"magically" use Win98SE with NTFS (assuming 98 had been designed to work
with NTFS), I'm not exactly sure how much would be gained, but I don't think
it would be nothing, as you seem to imply.
> I said that as long as the file system is doing it's job, and it's
> writing data accurately to files and retrieving them accurately for the
> OS above it, then you can't point to file-system differences as factors
> in measuring OS stability. Both NTFS and FAT32 correctly write and read
> file data the vast majority of the time, and neither of them can perform
> magic when sectors containing desired file data go bad.
>
>> What, exactly, is a "logically corrupted file"?
>
> A file that upon a read operation does not contain the data it's
> supposed to because of logical file construction errors (cross-linked
> clusters or trunkated chain). In other words, anything that was not
> caused by a physical fault of the recording media or some other hardware
> or electrical fault in or of the recording system.
OK. (Athough I think the latter is pretty rare in the vast majority of
situations, so maybe it's not even necessary to use that phrase. :-) At
least I'm not into any forensic or catastrophic recovery work)
>>> Journalling does not result in or increase file recoverability.
>>> System files are never journaled because they're never written
>>> or over-written or re-written. Journalling serves only to
>>> clean up any mess that's left behind if a file-write operation
>>> is improperly terminated.
>>
>> And you don't think that's ever helpful or useful?
>
> Actually, in some cases it's a detriment.
>
> Case in point:
>
> Our web server (running SP4) is powered via a large UPS. The batteries
> in the UPS were at their expiry point (which I didn't realize) and were
> not capable of running the server for more than 1 second during power
> interruptions.
Wow. Now THAT is pretty bad. However, the problem lies right there in
not checking out the batteries. Actually, one would think the UPS could
have some way of checking this out periodically (the backup battery
integrity) as part of its design.
> A few months ago during a period of flaky power, I was
> copying some web-log files from the server across the network to my
> win-98 system. But I noticed later that when I went to retrieve the
> same files from the server a day or two later, that they contained
> substantially less, and sometimes no data for that day. My copies of
> those log files that I had copied on those days actually contained more
> data. It was because of this discovery that I figured out that the
> system was shutting down unexpectedly, and the failure of the UPS
> batteries was the reason. But NTFS journaling garanteed that because
> IIS keeps it's log file open for the entire day, and only closes it just
> after midnight the next day, that it reverted to it's journaled state
> after being restarted, and hence we lost the majority of the data in
> those log files for those days. I'd call that a situation where
> journaling was un necessary and caused a loss of valuable data.
OK. Although I'm not sure this case is all that typical for most users.
>>> But you fault FAT32 and scandisk for giving you the option to
>>> save lost fragments to chk files, and then complain and point
>>> the finger at those files and say FAT32 sucks.
>
>>> But when 2K/XP has to perform it's own NTFS chkdsk, and it
>>> automatically deletes it's version of orphaned fragments,
>>> that's different - isn't it? Of course not.
>
>>> You don't see them on NTFS because they're automatically
>>> deleted when an improper shutdown was detected. NT doesn't
>>> give you the option to recover them.
>>
>> Well, it's not much of a "loss".
>
> No it's not. But in my example above, a FAT32 file system would have
> maintained all data that had been written to the file up to the point of
> unexpected system shut-down. The roll-back to the journaled version of
> the file was, in fact, detrimental.
OK. But this was due to a serious error from the batteries being OTL, and
where you didn't want the latest "journals" (which seems pretty atypical!).
What about the opposite case, the more typical case, where the journaling
would be beneficial?
> But beyond that, I'm trying to get you to understand that the .chk files
> you see in a FAT32 volume are not examples of any sort of failure or
> "lack of robustness" of the file system. It's because the default
> behavior of win-9x scandisk is to preserve lost clusters and file
> fragments, while the default behavior of NTFS is to delete them. You
> think that because you never see them on an NTFS file system, that they
> never existed in the first place. That's where your perception is
> wrong.
Actually, I don't know if I had assumed THAT.
>>>> You honestly don't believe NTFS is more advanced than FAT32?
>>>
>>> Is an 18-wheeler more advanced compared to a Honda Civic?
>>
>> Not if I'm truckin' across country with a heavy load.
>
> And as a percentage of vehicles on the road, there are more cars than
> trucks.
>
>> You didn't answer my question above.
>
> If I fail to answer questions, please restate them, so I know exactly
> what the question is.
>
> I believe you are referring to this question:
>
>>>> You honestly don't believe NTFS is more advanced than FAT32?
>
> You are trying to get me to say that NTFS is more advanced, so you can
> say that I agree that NTFS is "better" or more desirable than FAT32.
Perhaps, since you seem to suggest the contrary, carte blanche.
> There is no question that the NTFS specifications allow for a file
> system that contains more meta-data than FAT32.
Right.
> I'm not totally
> convinced that the journaling aspect is soley within the domain of the
> file system, and not partially (or substantially) handled or performed
> by the overlying NT operating system.
It's likely the integration of BOTH.
> If something is "advanced", to me it means that it has features that are
> useful to the user compared to the alternative. NTFS has features that
> FAT32 does not.
Indeed. And not only for multi-users.
> I do not believe those features are useful or
> beneficial to (or even noticed by) the vast majority of users.
Maybe. But again, with Win9x, which is in itself somewhat limited, we
are constrained to using FAT, and any limitations of such.
> Those features, I believe, come at a cost, which should not happen with
> an "advancement". The cost being the potential for a more complex,
> time-consuming and expensive repair event should it fail. And certainly
> the overhead of NTFS gives FAT32 a performance edge.
>
> (I did some internet searching for this question, but it's a difficult
> thing to find an answer to: If an NT-based OS like XP is installed on a
> FAT32 volume, is it not possible for it to impliment a form of
> journaling on it? Do we know for sure that such journaling _doesn't_
> happen in that case?)
I don't know, but I would assume it does not.
>> Nor have you ever addressed the problem with the ridiculous and
>> limited cluster size limitations, and the max allowable partition
>> sizes with FAT32 (more below).
>
> Yes, see my response (below).
>
>> Or that stupid 64K heap limitation, and occasionally running out
>> of resources (or coming close to the edge).
>
> The 64k heap is a limitation of win-98, and has nothing to do with FAT32
> vs NTFS.
True enough. But I thought we were touting Win98 in here too, and of
course with Win9x you MUST use FAT. :-) (Just FYI, I *do* appreciate
Win98SE, but have mostly moved on, although my second (backup) system here
is Win98SE)
>>> As a file system, FAT32 can allocate cluster size as efficiently
>>> (or as inefficiently) as NTFS.
>>
>> NO. If you have a large partition, you are FORCED to use a large
>> cluster size (like 32 KB is being used to store ANY single file,
>> even a one byte file).
>
> And here is where you are so wrong.
>
> The specifications for FAT32 allow for complete freedom to choose the
> cluster size irregardless of volume size.
Only IF the operating system can accept and handle it. Otherwise it would
be a moot point.
> Time and time again I've pointed this out.
>
> Time and time again I've stated how I've formatted large hard drives
> with FAT32 volumes with specific cluster sizes. Perhaps you go out of
> your way not to read those posts, or you cover your eyes in disbelief.
I didn't see them, that's all.
> I've formatted a 500 gb SATA drive as a single FAT32 volume, using 4kb
> cluster size, resulting in 120 million clusters, and have sucessfully
> installed and run win-98 on that drive.
>
> I've formatted 250 gb and 80 gb drives as single FAT32 volumes using 4kb
> cluster size and have successfully installed and run win-XP sp2 and sp3
> on them.
>
> You are confusing how Microsoft chose to scale cluster size on FAT32
> compared to what the FAT32 specification actually allows.
>
> Microsoft implimented this scaling in the native drive preparation /
> formatting programs (format.com). The OS's themselves (9x, NT) do not
> enforce these rules or require their adherence if you circumvent them
> with third-party drive preparation tools.
Like?
> Microsoft *CHOSE* to increase FAT32 cluster size with volume size. They
> have offered some reasons for that, and I've shown how some of those
> reasons are false.
Really? Microsoft offered "false reasons"? Like what? (given the
limitations of a 16 bit word used to store the number of clusters used in
the Win9x operating system, as I recall, or maybe you're not disputing at
least that part)
> DOS scandisk, for one, can actually operate on the
> large 500 gb volume with 120 million clusters, even though Microsoft
> said the stated limit for scandisk is 4.17 million clusters.
>
>
>And while the win-9x versions of scandisk and defrag are indeed limited to
> 4.17 million clusters, the win-me versions are not.
Again, is that documented somewhere? Why would ME be any different,
assuming it's still using (and limited by) a 16 bit word to store the number
of clusters?
> When it comes to any NT-based OS, those reasons simply do not exist.
> There is certainly no reason why the FAT32 cluster count can't exceed 4
> million for NT/2k/XP since there is no 16-bit file maintainence tools in
> those OS's.
But it's not just the "maintenance" tools, I think. If the *operating
system* code is
using a 16 bit word to store and reference the number of clusters, you are
somewhat constrained by that limit too.
> Since Microsoft could not "handicap" the use of FAT-32 on
> NT-based OS's, they decided to handicap the OS's themselves by taking
> away their ability to create FAT32 volumes larger than 32 gb.
>
>>> NTFS hard limits for file size, volume size and drive size are
>>> much larger than FAT32. Are those higher limits needed in
>>> the real world? In my opinion, rarely for some, never for most.
>>
>> Yes, see above. Today 250 GB and larger disks are common.
>
> Again another confusion.
>
> The FAT32 specification is not limited to hard drive size or volume size
> until you reach or exceed 2.2 tb.
Sorry, I meant *partition size*. You're now saying you can (if you
wanted) have a 2.2 TB partition?
> Now please understand the following points:
>
> 1) Win-9x comes with a protected-mode IDE driver, the file name
> is ESDI_506.PDR. That file is not capable of correctly
> handling a hard drive larger than 128 gb. That is not a
> FAT32 issue. That is a sector-addressing issue within
> that file.
>
> 2) If ESDI_506.PDR on win-9x is replaced with an alternative
> driver, then the 128 gb drive-size limitation is removed
> and drives larger than 128 gb can be attached to win-98
> systems and fully utilized.
I vaguely remember reading something about that. I don't recall what the
process was to replace that, but I guess it wasn't too involved. (I'm
assuming one couldn't just "copy it" over)
But again, I meant to refer to the max *partition* size with FAT32. What
is that specific limit? I don't think its 2.2 TB. (NOT for the max
disk size, but max partition size).
> 3) NT-based OS's were also limited to 128 gb drives for
> the same reason as win-98 until XP-SP2 and 2K-sp4. With
> those service packs, they became compatible with drives
> larger than 128 gb (presumably up to the full spec allowed
> by NTFS).
>
>>> If the only fault you can point to regarding FAT32 is the
>>> collection of .CHK files that *can* accumulate ...
>>
>> Sorry, but that was NOT the only fault I pointed out. I
>> mentioned SEVERAL ...
>
> Yes, you have.
>
> And I've now given a rebuttal to those. What do you say in response?
Well, see above. :-)
Ninty8 Guy
> > Because win-9x is not a multi-processing OS, it really didn't
> > need to "protect" the hardware from user apps.
>
> But that's not the only reason. Even if weren't, it would
> still be desireable, no?
I don't know about that. If an app wants to directly access the
hardware, then it's probably got a good reason for wanting to. Maybe
that's why the app was bought / installed in the first place.
> > You implied that because NTFS is more "advanced", that it helps
> > give NT a stability edge over 9x, because you equate "advanced"
> > with "robust".
>
> *In conjunction with* the operating system, XP. If one could
> somehow "magically" use Win98SE with NTFS (assuming 98 had been
> designed to work with NTFS), I'm not exactly sure how much would
> be gained, but I don't think it would be nothing, as you seem
> to imply.
Conversely, since I have installed XP on FAT32 volumes, then you would
expect something has been lost - in terms of "stability" ?
I've been working with about a dozen win-98 systems on a daily basis on
drives 40 gb and larger since, oh, 2003 or 2004. This concept of
instability is just not something I've experienced with these systems.
I must say that looking back at the 1998 - 2001 time frame, when hard
drives were spanning the 1 gb to 10 gb capacity range, and I look at
all the old legacy backup devices we had for our NT4 servers back then,
they're all just gathering dust now (various tape drives, Travan, etc).
Back then, there was this real fear, this real expectation, that your NT
drive needed to be constantly backed up, even if it did have this
magical thing called journaling.
Looking back, when drives crossed into the 20 or maybe the 40 gb range,
reliability seemed to increase dramatically.
So for me, this whole thing about FAT32 vs NTFS is not about file-system
reliability.
Since I'm still a hard-core 98 user, naturally I'm still using FAT32.
But even if I had the choice, I have absolutely ZERO need for all the
extra meta-baggage that comes with NTFS, and I find the idea of not
having true, pure, command-line access to my files a repulsive concept.
I guess because I did experience various hard drive failures while using
Win3x and Win95 back when hard drives were less than 10 gb (even less
than 5 gb), I certainly recall using FAT repair tools quite a bit back
then (norton, etc) and regardless how munged the drive looked from DOS,
the tools always seemed to bring the file system back to life. Hence my
impression that FAT is a very "accessible", or open and repairable file
system.
I did have one important 8 gb hard drive (FAT32) that was really screwed
up. I used software called "Lost and Found" and it performed some sort
of miracle on the drive (I had to attach a second blank drive to the
system and boot L&F from a floppy). After a few hours it reconstructed
a working copy of the dammaged drive on the second drive. After that
experience, I've come to believe that FAT32 is virtually indestructible.
> > I'd call that a situation where journaling was un necessary
> > and caused a loss of valuable data.
>
> OK. Although I'm not sure this case is all that typical for
> most users.
Almost everywhere you read about journaling, they make the case that
journaling does not "save" your data. It simply will roll back the file
system to the last known good state. That means you will lose data that
was being written since that last state but not yet journaled.
User data will be sacrificed for the sake of maintaining file system
integrity. That is a weakness of NTFS (that it is so easily made
vulnerable by incomplete file transactions).
On the other hand, FAT32's integrity is not comprimised by incomplete
file transactions, even if it does lead to the creation of lost
fragments.
> > But in my example above, a FAT32 file system would have
> > maintained all data that had been written to the file up
> > to the point of unexpected system shut-down. The roll-
> > back to the journaled version of the file was, in fact,
> > detrimental.
>
> OK. But this was due to a serious error from the batteries
> being OTL, and where you didn't want the latest "journals"
> (which seems pretty atypical!).
If you read CQuirke's commentary, he makes a point of saying that there
are planned and unplanned file-system events and that NTFS is given more
credit for "saving" a file system from unplanned events than it actually
accomplishes. A system (or drive) that loses power (for what-ever
reason) is exactly the reason that you look to the design of the file
system and assess it's claims of "robustness" or recovery potential.
> What about the opposite case, the more typical case, where the
> journaling would be beneficial?
If an NTFS volume has to be rolled back to a journaled state (for
what-ever reason), then the odds are high that some user data will be
lost - assuming there was a user sitting at the keyboard creating data
that was being periodically saved, or perhaps it's a server that was
receiving network data or a file or an e-mail or it was writing data to
a log file.
I honestly don't see the benefit of journaling, seeing that I've never
encountered a situation on a FAT32 drive where journaling would have
made any difference or would have been desirable.
On paper, journaling looks like a good idea. In practice, it seems
inconsequential.
> > You are trying to get me to say that NTFS is more advanced,
> > so you can say that I agree that NTFS is "better" or more
> > desirable than FAT32.
>
> Perhaps, since you seem to suggest the contrary, carte blanche.
Like so many things from Microsoft, once you strip away the hype, the
truth looks small and bland.
Microsoft will say a lot to justify each new OS or each new technology
they come out with. The average PC user simply does not need most of
what NTFS is or does. And it does come at a price. The price of
accessibility, of openness. Openness to third party tools, and
certainly to other non-MS operating systems (various forms of unix for
example).
> > I do not believe those features are useful or beneficial to
> > (or even noticed by) the vast majority of users.
>
> Maybe. But again, with Win9x, which is in itself somewhat
> limited, we are constrained to using FAT, and any limitations
> of such.
Microsoft has come to fear FAT32. To the irrational extent that it
intentionally crippled 2K and XP from being able to create FAT32 volumes
larger than 32 gb. FAT32 is too open for them, possibly even public
domain (depending on what court verdict you read).
> > The specifications for FAT32 allow for complete freedom to
> > choose the cluster size irregardless of volume size.
>
> Only IF the operating system can accept and handle it.
> Otherwise it would be a moot point.
And as I've said, I've discovered two very important things regarding
FAT32 that I have yet to find acknowledged anywhere else on the
internet:
1) It is universally believed that FAT32 cluster size MUST scale or
increase as the volume size is increased. I've found that is
patently false.
2) Windows 98se and XP-pro have absolutely no problems being installed
on and running from FAT32 volumes where the cluster-count far
exceeds the stated 4.17 million maximum according to Microsoft.
The implications of (1) and (2) is that the "waste" or "inefficiency"
issue that FAT32 gets a bad rap for is completely untrue, because if you
want a 40, 80, 160, 320 or 500 gb volume to have a cluster size of 4kb,
then FAT32 will do it, and Win-98 and XP will like it just fine.
> > The OS's themselves (9x, NT) do not enforce these rules or
> > require their adherence if you circumvent them with
> > third-party drive preparation tools.
>
> Like?
Every hard drive maker has links to their own drive-preparation
software. Most times that software is just a customized / rebranded
version of OnTrack Disc Manager.
Western Digital has Data Lifeguard Tools:
http://support.wdc.com/download/dlg/DLG_V11_2.zip
Seagate has DiscWizard:
http://www.seagate.com/support/discwizard/DiscWizardSetup.en.exe
Maxtor Maxblast:
http://www.seagate.com/support/maxblast/MaxBlastSetup.en.exe
(note that Maxtor is owned by Seagate)
Disk Manager - QUANTUM:
http://www.geocities.com/yvanol03/dc952.zip
Samsung Disk Manager:
http://www.samsung.com/global/business/hdd/products/downloads/dm_creator.zip
I also recommend Hiren's BootCD:
http://www.hiren.info/pages/bootcd
http://en.wikipedia.org/wiki/Hiren's_Boot_CD
Hiren's contains some or most of the above software, in addition to many
third-party commercial software like Partition Magic, Acronis Disk
Director, Paragon Partition Manager, Acronis True Image, Ontrack Disk
Manager, etc.
Here's a link to version 9.5 of Hiren's:
http://thepiratebay.org/torrent/4105716/Hiren_s_BootCD_9.5
> > Microsoft *CHOSE* to increase FAT32 cluster size with volume size.
> > They have offered some reasons for that, and I've shown how some
> > of those reasons are false.
>
> Really? Microsoft offered "false reasons"? Like what?
According to this:
(you will need to assemble these 2 lines into a single-line URL)
http://support.microsoft.com/default.aspx?scid=
http://support.microsoft.com:80/support/kb/articles/Q184/0/06.ASP&NoWebContent=1
"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)."
I have found that if a win-98 system is booted into DOS mode, with
himem.sys loaded, that it will easily scan a hard drive that has a much
higher cluster-count than the 4.177 million claimed by Microsoft as the
upper limit for scandisk. The largest drive I've tried it on so far had
120 million clusters.
Some of what Microsoft says on that page is true (or, at least, I don't
have any issues with it). Such as:
"The maximum possible number of clusters on a volume using the
FAT32 file system is 268,435,445. With a maximum of 32 KB per
cluster with space for the file allocation table (FAT), this
equates to a maximum disk size of approximately 8 terabytes
(TB)."
Here is another statment on that page that is wrong (or out-right lie):
"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."
> > And while the win-9x versions of scandisk and defrag are indeed
> > limited to 4.17 million clusters, the win-me versions are not.
>
> Again, is that documented somewhere?
There is some mention of using ME versions of scandisk and defrag on
win-98 systems on the msfn.org website (windows-9x forum). But not for
the same reasons.
I first documented my experiences with the Win-me versions back in 2007
here in this newsgroup (look for a series of posts titled "Cluster size
and exploring the limits of FAT-32").
> Why would ME be any different, assuming it's still using
> (and limited by) a 16 bit word to store the number of clusters?
There is evidence that a cluster count of 6,291,204 may represent some
sort of "magic" number when it comes to compatibility with some software
(norton disk doctor and scandisk for example). The windows ME versions
of scandisk and defrag functioned fine on drives with up to at least
31.2 million clusters. The win-98se versions were indeed limited to
4.177 million.
I noticed Bill that you seemed to have participated in that thread, back
on Feb 25 / 2007 (and so did cquirke).
> But it's not just the "maintenance" tools, I think. If the
> *operating system* code is using a 16 bit word to store and
> reference the number of clusters, you are somewhat constrained
> by that limit too.
Well, like I said back in 2007, Win-98se had no problems running from a
500 gb volume with 120 million clusters. Actually, it did have one
problem. It refused to create a swap file on that drive.
> > And I've now given a rebuttal to those. What do you
> > say in response?
>
> Well, see above. :-)
And likewise... :)
Bill in Co.
> "Bill in Co." wrote:
>
>>> Because win-9x is not a multi-processing OS, it really didn't
>>> need to "protect" the hardware from user apps.
>>
>> But that's not the only reason. Even if weren't, it would
>> still be desireable, no?
>
> I don't know about that. If an app wants to directly access the
> hardware, then it's probably got a good reason for wanting to. Maybe
> that's why the app was bought / installed in the first place.
Just improved speed, that's all. Is that a good reason? Well, obviously
they think so, even if they have to cut some corners (in the stability
dept).
>>> You implied that because NTFS is more "advanced", that it helps
>>> give NT a stability edge over 9x, because you equate "advanced"
>>> with "robust".
>>
>> *In conjunction with* the operating system, XP. If one could
>> somehow "magically" use Win98SE with NTFS (assuming 98 had been
>> designed to work with NTFS), I'm not exactly sure how much would
>> be gained, but I don't think it would be nothing, as you seem
>> to imply.
>
> Conversely, since I have installed XP on FAT32 volumes, then you would
> expect something has been lost - in terms of "stability" ?
I would expect so. It would be interesting to try it out sometime,
although I'm feeling a bit lazy about doing it and having to get another
drive and reinstall everything, but who knows, maybe someday. Then again,
with the complexity and inherent stability of WinXP anyways, I'm not sure
it's all that useful.
> I've been working with about a dozen win-98 systems on a daily basis on
> drives 40 gb and larger since, oh, 2003 or 2004. This concept of
> instability is just not something I've experienced with these systems.
Well, maybe you haven't been messin around with them as much as I have with
all the various (mostly shareware) programs I've played around with over
time. And also walking "a bit on the edge" in regards to some of my
"experiments" (I have little aversion to getting into the registry with
regedit when the need arises, to either customize or fix something, etc,
etc). One case in point was that swapping out of those two browse DLLs, to
finally get Windows Explorer NOT to hang on a large number of file deletes
(this happened when IE6 came into the picture). I don't know if you were
around then when we were discussing that in here.
> I must say that looking back at the 1998 - 2001 time frame, when hard
> drives were spanning the 1 gb to 10 gb capacity range, and I look at
> all the old legacy backup devices we had for our NT4 servers back then,
> they're all just gathering dust now (various tape drives, Travan, etc).
> Back then, there was this real fear, this real expectation, that your NT
> drive needed to be constantly backed up, even if it did have this
> magical thing called journaling.
>
> Looking back, when drives crossed into the 20 or maybe the 40 gb range,
> reliability seemed to increase dramatically.
>
> So for me, this whole thing about FAT32 vs NTFS is not about file-system
> reliability.
>
> Since I'm still a hard-core 98 user, naturally I'm still using FAT32.
> But even if I had the choice, I have absolutely ZERO need for all the
> extra meta-baggage that comes with NTFS, and I find the idea of not
> having true, pure, command-line access to my files a repulsive concept.
And I do miss that to some degree. And I acknowledged that in the
discussions with Cquirke. But I don't find it "repulsive", per se. But
it is a bit of a nuisance. But then again, I haven't yet had the need to
have that "pure command line access" to my files.
> I guess because I did experience various hard drive failures while using
> Win3x and Win95 back when hard drives were less than 10 gb (even less
> than 5 gb), I certainly recall using FAT repair tools quite a bit back
> then (norton, etc) and regardless how munged the drive looked from DOS,
> the tools always seemed to bring the file system back to life. Hence my
> impression that FAT is a very "accessible", or open and repairable file
> system.
But that was then, and this is now.
> I did have one important 8 gb hard drive (FAT32) that was really screwed
> up. I used software called "Lost and Found" and it performed some sort
> of miracle on the drive (I had to attach a second blank drive to the
> system and boot L&F from a floppy). After a few hours it reconstructed
> a working copy of the dammaged drive on the second drive. After that
> experience, I've come to believe that FAT32 is virtually indestructible.
>
>>> I'd call that a situation where journaling was un necessary
>>> and caused a loss of valuable data.
>>
>> OK. Although I'm not sure this case is all that typical for
>> most users.
>
> Almost everywhere you read about journaling, they make the case that
> journaling does not "save" your data. It simply will roll back the file
> system to the last known good state.
Which can be very helpful, and often is desireable.
> That means you will lose data that
> was being written since that last state but not yet journaled.
But it may have been lost anyway, under any system.
> User data will be sacrificed for the sake of maintaining file system
> integrity. That is a weakness of NTFS (that it is so easily made
> vulnerable by incomplete file transactions).
I don't agree with this summary as such a blanket statement (with the
concurrent implication that using FAT would have prevented that, and saved
the day, for any and all file recovery). I think that argument is a bit
hyperbolic.
> On the other hand, FAT32's integrity is not comprimised by incomplete
> file transactions, even if it does lead to the creation of lost fragments.
I guarantee you that I can pretty well mess up a file "transaction" (like
writing the file) in FAT if I do something drastic to the system (like pull
the plug during the file write) Or a blue screen might occur, while
another program is running (and it causedf the blue screen) right in the
middle of this file write operation. So nothing is guaranteed, no matter
what you are using.
>>> But in my example above, a FAT32 file system would have
>>> maintained all data that had been written to the file up
>>> to the point of unexpected system shut-down.
What happens if I interrupt it halfway through its disk write? Like pull
the plug?
Or maybe another program running causes a blue screen in the middle of a
write operation?
>>> The roll-back to the journaled version of the file was, in fact,
>>> detrimental.
>>
>> OK. But this was due to a serious error from the batteries
>> being OTL, and where you didn't want the latest "journals"
>> (which seems pretty atypical!).
>
> If you read CQuirke's commentary, he makes a point of saying that there
> are planned and unplanned file-system events and that NTFS is given more
> credit for "saving" a file system from unplanned events than it actually
> accomplishes.
How much more? And are you implying it gives NONE?
> A system (or drive) that loses power (for what-ever
> reason) is exactly the reason that you look to the design of the file
> system and assess it's claims of "robustness" or recovery potential.
>
>> What about the opposite case, the more typical case, where the
>> journaling would be beneficial?
>
> If an NTFS volume has to be rolled back to a journaled state (for
> what-ever reason), then the odds are high that some user data will be
> lost - assuming there was a user sitting at the keyboard creating data
> that was being periodically saved, or perhaps it's a server that was
> receiving network data or a file or an e-mail or it was writing data to
> a log file.
But that data might also well be lost using Win9x and FAT. Using FAT gives
no guarantee, either.
> I honestly don't see the benefit of journaling, seeing that I've never
> encountered a situation on a FAT32 drive where journaling would have
> made any difference or would have been desirable.
>
> On paper, journaling looks like a good idea. In practice, it seems
> inconsequential.
Well, according to you, anyways.
>>> You are trying to get me to say that NTFS is more advanced,
>>> so you can say that I agree that NTFS is "better" or more
>>> desirable than FAT32.
>>
>> Perhaps, since you seem to suggest the contrary, carte blanche.
>
> Like so many things from Microsoft, once you strip away the hype, the
> truth looks small and bland.
>
> Microsoft will say a lot to justify each new OS or each new technology
> they come out with. The average PC user simply does not need most of
> what NTFS is or does. And it does come at a price. The price of
> accessibility, of openness. Openness to third party tools, and
> certainly to other non-MS operating systems (various forms of unix for
> example).
>
>>> I do not believe those features are useful or beneficial to
>>> (or even noticed by) the vast majority of users.
>>
>> Maybe. But again, with Win9x, which is in itself somewhat
>> limited, we are constrained to using FAT, and any limitations
>> of such.
>
> Microsoft has come to fear FAT32.
Oh come on, now. (This is again a bit hyperbolic).
> To the irrational extent that it
> intentionally crippled 2K and XP from being able to create FAT32 volumes
> larger than 32 gb. FAT32 is too open for them, possibly even public
> domain (depending on what court verdict you read).
>
>>> The specifications for FAT32 allow for complete freedom to
>>> choose the cluster size irregardless of volume size.
I still don't believe that. Cites please ? (And I mean authoritative and
fully documented, not newsgroup related, or someone's opinion)
>> Only IF the operating system can accept and handle it.
>> Otherwise it would be a moot point.
>
> And as I've said, I've discovered two very important things regarding
> FAT32 that I have yet to find acknowledged anywhere else on the
> internet:
>
> 1) It is universally believed that FAT32 cluster size MUST scale or
> increase as the volume size is increased. I've found that is
> patently false.
Well, but you may be the only one. I haven't heard anybody else here deny
it, and the documented articles on the net tend to support it (i.e. that
limitation). Where are the articles showing it is false, and that you can
use ANY cluster size you like in FAT32, *no matter how large the partition
is*? Can you provide an authenticate, documented, authoritative link,
from a software company, for instance?
> 2) Windows 98se and XP-pro have absolutely no problems being installed
> on and running from FAT32 volumes where the cluster-count far
> exceeds the stated 4.17 million maximum according to Microsoft.
Again, you say that.
> The implications of (1) and (2) is that the "waste" or "inefficiency"
> issue that FAT32 gets a bad rap for is completely untrue, because if you
> want a 40, 80, 160, 320 or 500 gb volume to have a cluster size of 4kb,
> then FAT32 will do it, and Win-98 and XP will like it just fine.
Again - got a documented, authentic, cite to back that up? (and not just
someone in this newsgroup?)
>>> The OS's themselves (9x, NT) do not enforce these rules or
>>> require their adherence if you circumvent them with
>>> third-party drive preparation tools.
>>
>> Like?
>
> Every hard drive maker has links to their own drive-preparation
> software. Most times that software is just a customized / rebranded
> version of OnTrack Disc Manager.
>
> Western Digital has Data Lifeguard Tools:
> http://support.wdc.com/download/dlg/DLG_V11_2.zip
NO. That will NOT let you create and select any cluster size you like, for
any partition size you like, in FAT32. Sorry, no go. Ditto on the rest
below.
> Seagate has DiscWizard:
> http://www.seagate.com/support/discwizard/DiscWizardSetup.en.exe
>
> Maxtor Maxblast:
> http://www.seagate.com/support/maxblast/MaxBlastSetup.en.exe
>
> (note that Maxtor is owned by Seagate)
>
> Disk Manager - QUANTUM:
> http://www.geocities.com/yvanol03/dc952.zip
>
> Samsung Disk Manager:
> http://www.samsung.com/global/business/hdd/products/
downloads/dm_creator.zip
> I also recommend Hiren's BootCD:
> http://www.hiren.info/pages/bootcd
> http://en.wikipedia.org/wiki/Hiren's_Boot_CD
>
> Hiren's contains some or most of the above software, in addition to many
> third-party commercial software like Partition Magic, Acronis Disk
> Director, Paragon Partition Manager, Acronis True Image, Ontrack Disk
> Manager, etc.
Again, these do NOT allow you to do what you say, with 4K cluster sizes for
large partitions, etc. This has nothing to do with what we are discussing.
> Here's a link to version 9.5 of Hiren's:
>
> http://thepiratebay.org/torrent/4105716/Hiren_s_BootCD_9.5
>
>>> Microsoft *CHOSE* to increase FAT32 cluster size with volume size.
>>> They have offered some reasons for that, and I've shown how some
>>> of those reasons are false.
>>
>> Really? Microsoft offered "false reasons"? Like what?
>
> According to this:
>
> (you will need to assemble these 2 lines into a single-line URL)
>
> http://support.microsoft.com/default.aspx?scid=
> http://support.microsoft.com:80/support/
kb/articles/Q184/0/06.ASP&NoWebContent=1
> "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).
NOTE: Here is the KEY line:
> Including the FATs themselves, this works
> out, at the maximum of 32 KB per cluster, to a volume size of
> 127.53 gigabytes (GB)."
There ya go. :-) So - the largest FAT partition is 127 GB, according
to the authority on it.
> I have found that if a win-98 system is booted into DOS mode, with
> himem.sys loaded, that it will easily scan a hard drive that has a much
> higher cluster-count than the 4.177 million claimed by Microsoft as the
> upper limit for scandisk. The largest drive I've tried it on so far had
> 120 million clusters.
>
> Some of what Microsoft says on that page is true (or, at least, I don't
> have any issues with it). Such as:
>
> "The maximum possible number of clusters on a volume using the
> FAT32 file system is 268,435,445. With a maximum of 32 KB per
> cluster with space for the file allocation table (FAT), this
> equates to a maximum disk size of approximately 8 terabytes
> (TB)."
Note: Maximum DISK size. NOT maximum *partition size*. So you could
have lots of *smaller partitions*, but only up to the limit of 8 TB for the
entire hard drive. And those smaller partitions would be limited to 127 GB
from the Microsoft article above.
> Here is another statment on that page that is wrong (or out-right lie):
Well according to you. Again, got any certifiable documented cites?
> "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."
>
>>> And while the win-9x versions of scandisk and defrag are indeed
>>> limited to 4.17 million clusters, the win-me versions are not.
>>
>> Again, is that documented somewhere?
>
> There is some mention of using ME versions of scandisk and defrag on
> win-98 systems on the msfn.org website (windows-9x forum). But not for
> the same reasons.
>
> I first documented my experiences with the Win-me versions back in 2007
> here in this newsgroup (look for a series of posts titled "Cluster size
> and exploring the limits of FAT-32").
No offense, but your documentation is not sufficient for me. I need an
authoritative documented source, say from the likes of some of the companies
that produce the software, and/or Microsoft, which DESIGNED the system,
afterall.
>> Why would ME be any different, assuming it's still using
>> (and limited by) a 16 bit word to store the number of clusters?
>
> There is evidence that a cluster count of 6,291,204 may represent some
> sort of "magic" number when it comes to compatibility with some software
> (norton disk doctor and scandisk for example). The windows ME versions
> of scandisk and defrag functioned fine on drives with up to at least
> 31.2 million clusters. The win-98se versions were indeed limited to
> 4.177 million.
>
> I noticed Bill that you seemed to have participated in that thread, back
> on Feb 25 / 2007 (and so did cquirke).
Yeah, I think I did. It's been awhile.
>> But it's not just the "maintenance" tools, I think. If the
>> *operating system* code is using a 16 bit word to store and
>> reference the number of clusters, you are somewhat constrained
>> by that limit too.
>
> Well, like I said back in 2007, Win-98se had no problems running from a
> 500 gb volume
Using more than one partition.
> with 120 million clusters. Actually, it did have one
> problem. It refused to create a swap file on that drive.
THAT would be a pretty serious problem! (Almost makes it useless, to me).
>>> And I've now given a rebuttal to those. What do you
>>> say in response?
>>
>> Well, see above. :-)
>
> And likewise... :)
And likewise. :-)
Ingeborg
Not knowing anything about the OP's hardware, except that it's able to run
W2000 (so at least a pentium with 32MB memory), I can't agree this is
irrelevant.
Ninety8 Guy
> > I used software called "Lost and Found" and it performed some
> > sort of miracle on the drive
>
> Where did you get that software?
Can you believe that I actually bought it? Probably cost $30.
I see that Hiren's boot CD has it, so that's probably the best place to
get it now.
MEB
to expound upon your purported tests, when, IN FACT, you have yet to perform
those tests in a form designed to actually test the disk in the fashion to
verify these abilities which you have CLAIMED to have exceeded.
You certainly did NOT perform the tests here, did NOT even finish the tests
you claimed to have performed {it came to a point that you assumed it would
work after several days [DOS] so you ended that test without finishing it},
nor did you do other than lay this *claim*,,, when confronted with the
specific tests which would have *verified* your claims, you refused to
perform them. You have been repeatedly directed to those original tests you
were to have performed, as recently as last month when you brought this
CLAIM, once again, to this group.
Do the tests or post this crap somewhere else. Do NOT claim you don't know
what those tests were.
--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______
"Ninty8 Guy" <Nin...@Guy.com> wrote in message
news:49E550B7...@Guy.com...
Ninety8 Guy
> Is there any reason, other than your own need for recognition,
> you continue to expound upon your purported tests
I described what my experiences were running win-98 (and XP) on large
FAT-32 volumes with small cluster size.
I described exactly what I did to test specifically the combination of
win-98 and drives with high cluster-counts. I may have said the tests
satisified my interests at the time. I never said that other tests
weren't possible.
I never said I wouldn't do any more tests, and I would do more if
someone had something specific in mind. You never described any such
specific test. You just blow hot air and spew generalities.
The fact is that I'd be a fool to chase my tail to satisfy you. You've
never describe a specific test despite my many requests, and you'd never
believe my results even it I performed them.
And why are you such a full-quoting fool?
Why can't you learn to edit and clean up your posts?
Do you enjoy being such a lazy bastard?
Ninety8 Guy
> What happens if I interrupt it halfway through its disk write?
> Like pull the plug?
Look. I gave an example where I copied an open log file from an NT
system, and a day or two later that same file had either much less or
actually no data compared to the copy. That would not have happened
under a FAT32 system. The reason that the file contained less or no
data is because when the system lost power (and it probably lost power
when that file was NOT being written to) NTFS rolled back to an earlier
journaled version of that file. The current version of that file was
probably just fine, but NT and NTFS is programmed not to trust file
versions that aren't journaled, hence the data was lost. That wouldn't
have happened under FAT32 because it simply isin't journaled and the
file system or the operating system would have no basis or reason for
tampering with or altering the file once the system was restarted.
> Or maybe another program running causes a blue screen in the
> middle of a write operation?
I think you have blue-screen on the brain. One of our developers has
an XP-pro system and I don't know what he does to it but it goes into
a blue-screen state at least once a day (actually 2 blue screens since
it's a dual monitor setup).
The only time I see blue-screens on my win-98 systems is when I pull a
USB memory stick out of them when they have an open explorer window on
them. And that's a harmless blue screen.
> > If an NTFS volume has to be rolled back to a journaled state
> > (for what-ever reason), then the odds are high that some user
> > data will be lost
>
> But that data might also well be lost using Win9x and FAT.
No. You still don't understand.
Under FAT32, if data is written to a file, there is no mechanism to
later trunkate the file and lose the last bit of data that was written
to the file if the system is unexpectedly turned off and restarted. If
a file is being added to over time (such as a user document or a system
log file) once the data is written to the drive, it stays there.
Under NTFS, if the system's power gets pulled, then upon re-start the
file system is looked at and any write transactions that weren't
classified as being completed are looked for and those files are
rolled-back to their last journaled state. That's why you lose data
under NTFS but not FAT32 in those situations.
> > Microsoft has come to fear FAT32.
>
> Oh come on, now. (This is again a bit hyperbolic).
>
> > To the irrational extent that it intentionally crippled 2K
> > and XP from being able to create FAT32 volumes larger than
> > 32 gb. FAT32 is too open for them, possibly even public
> > domain (depending on what court verdict you read).
You have nothing to say about that?
(I'm going to continue this reply in my next post)
Ninety8 Guy
> > Every hard drive maker has links to their own drive-preparation
> > software. Most times that software is just a customized /
> > rebranded version of OnTrack Disc Manager.
> >
> > Western Digital has Data Lifeguard Tools:
> > http://support.wdc.com/download/dlg/DLG_V11_2.zip
>
> NO. That will NOT let you create and select any cluster size you
> like, for any partition size you like, in FAT32. Sorry, no go.
> Ditto on the rest below.
Ok.
At this point, you're either trying to pull my leg, or you really
believe what you've just posted.
So because I don't know, I'll assume you really do believe what you've
just posted.
With regard to the WD Data Lifeguard software that you claim will not
let you choose your own FAT32 cluster size when preparing a drive, I
will post the following as proof of that capability or functionality.
Today I performed a drive-preparation session with the WD software and
an 80 GB WD hard drive. I took digital photographs of the screen during
each step of this process. The links to each photo is posted below.
Picture 1 is the main screen for the Western Digital Data Lifeguard
tools. Pictures 2 through 16 shows the entire process of selecting and
formatting an 80 gb WD hard drive as FAT32 with 4kb cluster size.
Pictures 8 through 12 specifically show the various cluster-size options
for FAT32. In this example, the 4kb cluster size is selected.
After the drive has been formatted and the DOS system files placed on
it, picture 17 shows chkdsk being run from a floppy after the system has
been booted from the formatted drive. Chkdsk clearly shows 4kb cluster
size, and about 19.5 million total clusters. Picture 18 shows the
system booting from the drive immediately after the post screen.
Several dos files were copied to the drive prior to this picture.
Himem.sys can be seen loading. Picture 19 is a dir command showing the
files in the root directory. Pictures 20 through 25 show scandisk.exe
being run. Picture 26 shows chkdsk being run, and a VER command being
executed.
I would have liked to post specific pages of the support documents for
that software, but they don't go into enough detail to show that yes,
you can use this software to choose your own cluster size when
formatting a fat32 volume.
Here are the pictures:
http://www.fileden.com/files/2009/4/15/2404980/01.jpg
http://www.fileden.com/files/2009/4/15/2404980/02.jpg
http://www.fileden.com/files/2009/4/15/2404980/03.jpg
http://www.fileden.com/files/2009/4/15/2404980/04.jpg
http://www.fileden.com/files/2009/4/15/2404980/05.jpg
http://www.fileden.com/files/2009/4/15/2404980/06.jpg
http://www.fileden.com/files/2009/4/15/2404980/07.jpg
http://www.fileden.com/files/2009/4/15/2404980/08.jpg
http://www.fileden.com/files/2009/4/15/2404980/09.jpg
http://www.fileden.com/files/2009/4/15/2404980/10.jpg
http://www.fileden.com/files/2009/4/15/2404980/11.jpg
http://www.fileden.com/files/2009/4/15/2404980/12.jpg
http://www.fileden.com/files/2009/4/15/2404980/13.jpg
http://www.fileden.com/files/2009/4/15/2404980/14.jpg
http://www.fileden.com/files/2009/4/15/2404980/15.jpg
http://www.fileden.com/files/2009/4/15/2404980/16.jpg
http://www.fileden.com/files/2009/4/15/2404980/17.jpg
http://www.fileden.com/files/2009/4/15/2404980/18.jpg
http://www.fileden.com/files/2009/4/15/2404980/19.jpg
http://www.fileden.com/files/2009/4/15/2404980/20.jpg
http://www.fileden.com/files/2009/4/15/2404980/21.jpg
http://www.fileden.com/files/2009/4/15/2404980/22.jpg
http://www.fileden.com/files/2009/4/15/2404980/23.jpg
http://www.fileden.com/files/2009/4/15/2404980/24.jpg
http://www.fileden.com/files/2009/4/15/2404980/25.jpg
http://www.fileden.com/files/2009/4/15/2404980/26.jpg
I honestly don't know what more I can do to prove to you that this
capability exists, and that most if not all of the software I mentioned
in my previous posts do actually allow the same choices for cluster
size.
If you want to be stubborn and chose to disregard these pictures and not
try this for yourself then I guess we have nothing more to talk about.
And for anyone else reading this, why don't you step forward and confirm
what I'm writing here?
Bill Blanton
> "Bill in Co." wrote:
>
>> What happens if I interrupt it halfway through its disk write?
>> Like pull the plug?
>
> Look. I gave an example where I copied an open log file from an NT
> system, and a day or two later that same file had either much less or
> actually no data compared to the copy. That would not have happened
> under a FAT32 system. The reason that the file contained less or no
> data is because when the system lost power (and it probably lost power
> when that file was NOT being written to) NTFS rolled back to an earlier
> journaled version of that file. The current version of that file was
> probably just fine, but NT and NTFS is programmed not to trust file
> versions that aren't journaled, hence the data was lost. That wouldn't
> have happened under FAT32 because it simply isin't journaled and the
> file system or the operating system would have no basis or reason for
> tampering with or altering the file once the system was restarted.
[snip]
> Under NTFS, if the system's power gets pulled, then upon re-start the
> file system is looked at and any write transactions that weren't
> classified as being completed are looked for and those files are
> rolled-back to their last journaled state. That's why you lose data
> under NTFS but not FAT32 in those situations.
I can see where that might be possible, but the power fail event would
have to happen right at the precise point between the actual write and
the point where the write transaction was recorded in the journal log.
In that case, the updated information for the file structure would be undone.
The new data might be on the disk, but it has no logical files pointers to it.
OTOH, if it happened during the write the data was mostly trashed
anyway.
You make a valid point there, but in your example of the IIS log file in your
previous post, you stated that it was because the file was only closed
once a day. An open file does not constitute a "transaction event".
Opening a file only allocates resources (file handle). If the file was
kept open, but still being written out periodically, you shouldn't have
lost the whole file. Not saying it didn't happen :), but maybe something
else was involved besides journaling.
Bill Blanton
> "Bill in Co." wrote:
>
>> > Every hard drive maker has links to their own drive-preparation
>> > software. Most times that software is just a customized /
>> > rebranded version of OnTrack Disc Manager.
>> >
>> > Western Digital has Data Lifeguard Tools:
>> > http://support.wdc.com/download/dlg/DLG_V11_2.zip
>>
>> NO. That will NOT let you create and select any cluster size you
>> like, for any partition size you like, in FAT32. Sorry, no go.
>> Ditto on the rest below.
>
> I honestly don't know what more I can do to prove to you that this
> capability exists, and that most if not all of the software I mentioned
> in my previous posts do actually allow the same choices for cluster
> size.
> And for anyone else reading this, why don't you step forward and confirm
> what I'm writing here?
I didn't look at the software or pics you posted, but I will confirm
that. You can choose cluster sizes with many third party tools.
BootitNG, (what I usually use) allows it.
Bill Blanton
> According to this:
> http://support.microsoft.com/default.aspx?scid=
> http://support.microsoft.com:80/support/kb/articles/Q184/0/06.ASP&NoWebContent=1
>
> "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)."
>
> I have found that if a win-98 system is booted into DOS mode, with
> himem.sys loaded, that it will easily scan a hard drive that has a much
> higher cluster-count than the 4.177 million claimed by Microsoft as the
> upper limit for scandisk.
Perhaps Microsoft wants to play it safe and assume some will boot
a floppy that does not load himem.sys and possibly have scandisk run
amok.
> The largest drive I've tried it on so far had
> 120 million clusters.
I remember reading some of your posts about this.
Just curious,, did you check how much total memory was reported
by mem?
If you did a /surface scan, was the correct number of clusters
reported?
It's probably safe to assume that none of the FAT was above 128GB.
Were any directories? Did you try cross-linking files below 128GB
with files above? Or 2 files above? Preferably specific known text
files so that you could check the resultant chk* files to see if scandisk
was actually where it thought it was.
> Some of what Microsoft says on that page is true (or, at least, I don't
> have any issues with it). Such as:
> "The maximum possible number of clusters on a volume using the
> FAT32 file system is 268,435,445. With a maximum of 32 KB per
> cluster with space for the file allocation table (FAT), this
> equates to a maximum disk size of approximately 8 terabytes
> (TB)."
That may be so but,,
Given that the size of the start and total LBA sector fields in the partition
table are 32-bits wide, it's only possible for a basic partition disk (with
512 byte sectors) to be 2TB. Above that you'd have to set it up as a GPT
disk. Neither 98 or XP 32-bit support GPT disks.
Bill in Co.
No, you're missing my point. Suppose the disk is in the middle of writing
out a large file (like a .wav file), and you pull the plug. What do YOU
expect will be the result? Surely you don't expect the file to be intact,
or in any way recoverable. Because it won't. The application that was
writing it (like an audio editor) will have failed to write it out. There
may be bits of it on the drive, but it's totally unrecoverable. (I'm not
just talking about a text file here)
> Under NTFS, if the system's power gets pulled, then upon re-start the
> file system is looked at and any write transactions that weren't
> classified as being completed are looked for and those files are
> rolled-back to their last journaled state. That's why you lose data
> under NTFS but not FAT32 in those situations.
>
>>> Microsoft has come to fear FAT32.
>>
>> Oh come on, now. (This is again a bit hyperbolic).
>>
>>> To the irrational extent that it intentionally crippled 2K
>>> and XP from being able to create FAT32 volumes larger than
>>> 32 gb. FAT32 is too open for them, possibly even public
>>> domain (depending on what court verdict you read).
>
> You have nothing to say about that?
Well, I don't believe that. That's just your spin on it.
Ninety8 Guy
> > I have found that if a win-98 system is booted into DOS mode,
> > with himem.sys loaded, that it will easily scan a hard drive
> > that has a much higher cluster-count than the 4.177 million
> > claimed by Microsoft as the upper limit for scandisk.
>
> Perhaps Microsoft wants to play it safe and assume some will
> boot a floppy that does not load himem.sys and possibly have
> scandisk run amok.
But even that is not true.
If I run scandisk without himem.sys, it usually (or always?) refuses to
run, stating explicitly that it needs himem.sys to be loaded.
> > The largest drive I've tried it on so far had
> > 120 million clusters.
>
> I remember reading some of your posts about this.
>
> Just curious,, did you check how much total memory was
> reported by mem?
You mean system ram?
I've run it with both 512mb and 1024 mb of ram. Didn't make a
difference - scandisk (dos version) ran fine either time. I really
don't think that the entire table(s) are completely loaded or present in
system RAM at any given moment when scandisk is running, unless perhaps
if the FAT tables are less than some arbitrarily small size (4 mb? 8
mb?)
> If you did a /surface scan, was the correct number of clusters
> reported?
In the case of the 500 gb drive with 120 million clusters, I stopped
scandisk after 24 - 36 hours of continuous running (I projected it would
have taken 3 days to complete based on it's progress). So no, in that
case I did not have the opportuning for the scan to be finished before
being presented the option to do a surface scan. I'm not familiar with
the /surface option - does that cause scandisk to immediately skip the
initial file system checks and go straight into the surface scan?
But even in that case, chkdsk correctly reported the number of clusters.
> It's probably safe to assume that none of the FAT was above 128GB.
You have to remember that on motherboards that are 48-bit LBA
compatible, that at the BIOS or DOS level there is no problem with
drives larger than 128 gb. Basically any motherboard made during or
after 2002 will have no hard drive size restrictions, and in that
situation DOS is inherently capable of seeing and properly reading /
writing to the entire drive.
But Win-98se will have a problem at the 128 gb boundary unless it's
protected mode driver (ESDI_506.PDR) is replaced with something else.
Several modified versions of that file are available, as well as an
alternative that's part of the Intel Application Accelerator for a
select few 8xx chipsets, as well as running the drives under a raid
controller if a win-98 driver is available.
> Given that the size of the start and total LBA sector fields
> in the partition table are 32-bits wide, it's only possible
> for a basic partition disk (with 512 byte sectors) to be 2TB.
For one thing, it depends on whether or not the sector size on a given
hard drive is 512 bytes or something larger. I believe it's possible
that some drives might indeed have 4kb sector size.
But in any case, the way I understand it, given a sector size of 512
bytes and a cluster size of 32kb, that FAT32 is limited to 2tb volume
size and 8tb ultimate hard drive size. Basically 4 volumes of 2tb each
on an 8tb drive, with each volume having 67 million clusters.
> Above that you'd have to set it up as a GPT
> disk. Neither 98 or XP 32-bit support GPT disks.
Hard drive capacity seems to be doubling every 2 years during the past
decade. In January this year, Western Digital started shipping the
first 2tb drives. If this rate holds, we should (or could) roughly
expect to see 8tb drives in 4 years. Plenty of time left to keep using
FAT32.
Bill in Co.
I wasn't just referring to that as a generality. Of course you have some
freedom in some of those programs (like BING) to select the cluster size,
but *ONLY within strict limits*. 98G said he could use 4K clusters on ANY
size partition on FAT32, and I think that is B.S. And - I'd like to see
some certifiable documentation on that - proving it.
Bill in Co.
> "Bill in Co." wrote:
>
>>> Every hard drive maker has links to their own drive-preparation
>>> software. Most times that software is just a customized /
>>> rebranded version of OnTrack Disc Manager.
>>>
>>> Western Digital has Data Lifeguard Tools:
>>> http://support.wdc.com/download/dlg/DLG_V11_2.zip
>>
>> NO. That will NOT let you create and select any cluster size you
>> like, for any partition size you like, in FAT32. Sorry, no go.
>> Ditto on the rest below.
>
> Ok.
>
> At this point, you're either trying to pull my leg, or you really
> believe what you've just posted.
>
> So because I don't know, I'll assume you really do believe what you've
> just posted.
>
> With regard to the WD Data Lifeguard software that you claim will not
> let you choose your own FAT32 cluster size when preparing a drive, I
> will post the following as proof of that capability or functionality.
Wait a minute. I did NOT say THAT. *What I said was*, you do NOT have
complete freedom in selecting any cluster size for a large partition when
using FAT32. There is a big difference there.
> Today I performed a drive-preparation session with the WD software and
> an 80 GB WD hard drive. I took digital photographs of the screen during
> each step of this process. The links to each photo is posted below.
OK, I'll take a look at them. But since I'm on dialup, it may take me
some time.
If what you say is true, I'll have to go back and find the Microsoft article
which lists the cluster size limitations.
Bill in Co.
But: I just tried out 2 programs, Partition Magic, and BING (BootItNG), and
neither one will allow me to create a 76 GB partition with 4K clusters.
Both
programs forced me to use 32 KB clusters. In fact, while I was in Partition
Magic, I played around with that more, by selecting 4K for the cluster size,
and steadily increasing the partition size, and the max partition size I
could select was 24.623 GB with 4K clusters, and 49.199 GB with 8K clusters.
So go figure.
MEB
"Ninety8 Guy" <Nin...@Guy.com> wrote in message
news:49E66804...@Guy.com...
> MEB wrote:
>
> > Is there any reason, other than your own need for recognition,
> > you continue to expound upon your purported tests
>
> I described what my experiences were running win-98 (and XP) on large
> FAT-32 volumes with small cluster size.
>
> I described exactly what I did to test specifically the combination of
> win-98 and drives with high cluster-counts. I may have said the tests
> satisified my interests at the time. I never said that other tests
> weren't possible.
ONCE AGAIN, **you** verify your tests were incomplete, AND FALSE IN NATURE.
>
> I never said I wouldn't do any more tests, and I would do more if
> someone had something specific in mind. You never described any such
> specific test. You just blow hot air and spew generalities.
BULLCRAP, as I pointed out to you in your last attempts at recognition as a
supposed tester, AND which you verified in your posts JUST A FEW WEEKS ago,
you are well aware of those tests. IF FACT I outlined the basics for you
once again. SO "shove this where the sun don't shine".... though likely
there isn't enough room as your head is up there already.
>
> The fact is that I'd be a fool to chase my tail to satisfy you. You've
> never describe a specific test despite my many requests, and you'd never
> believe my results even it I performed them.
>
> And why are you such a full-quoting fool?
>
> Why can't you learn to edit and clean up your posts?
Because moron, I was out here when you were either still in diapers, or
likely not even born.
Shall I describe HOW netiquitte came about,, think phoneline downloads from
BBSs with 2400 buad modems LONG DISTANCE and our determination that it was
reasonable to cut posts which contained little relevant materials to the
BONE for downloaders.
IN TODAYS world even with a phone modem, you at least have 56K [or around
there] so those concerns do not have the same relevance.. MOREOVER, as
techincal discussions [which you have difficulty participating in due to
apparent ignorance] are now listed in search engines. THEREFORE, ALL
relevant information should be left within ANY post as cutting materials
leaves the potential finder [via search engine query] with ineffective or
partial information.
NOW, IF {emphasis} you had half a brain I wouldn't have found it necessary
to explain this to you for the THIRD time.
>
> Do you enjoy being such a lazy bastard?
Do you enjoy being one of the most stupid people on this planet?
MEB
Petr/MSFN
LittyX/Lixaanli
From one of the large drive esdi_506.pdr modifiers:
FAQ
~~~
1. Can this driver be used with drives less than 128Gb?
> In most cases. The driver will switch over to extended commands past the
268,435,200th sector. Drives between 268,435,201 and 268,435,455 sectors
that do not implement the extended command set may malfunction at this
boundary condition.
2. Can this driver be used with SATA devices?
> "Though Serial ATA will not be able to directly interface with legacy
Ultra ATA hardware, it is fully compliant with the ATA protocol and
thus is software compatible." - SATA standard.
3. Differences between this and R.Loew's "High Capacity Disk Patch"?
> 1. HCDP is commercial software. Enable48BitLBA is freeware.
2. HCDP does not implement a separate register initialiser and commands
section (read,read_noDMA,write,write_noDMA,verify). This driver uses
a separated execution flow resulting in slightly better performance.
3. HCDP freeware only accesses up to 145Gb. Enable48BitLBA concievably
should work up to FAT32 addressing limit of 2048Gb (less one byte).
4. What about limits on partition sizes?
> This driver does not accept
Recent discussions:
http://www.msfn.org/board/index.php?showtopic=129027
http://www.msfn.org/board/Install-w98-Large-Drives-t113142.html
http://www.msfn.org/board/index.php?showtopic=113142&st=20&p=774781&#entry774781
I see see 98 Guy posted there with the same UNTESTED materials and
suggestions... even directing to his supposed posts in this group as
reference. EXCELLENT way to make fraud seem real.
PARTICULARLY, as Ninety8 Guy or 98 Guy has once again {this discussion}
confirmed the tests were NOT performed properly or fully.
--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______
"Ninety8 Guy" <Nin...@Guy.com> wrote in message
news:49E6AF57...@Guy.com...
Ninety8 Guy
> > I described exactly what I did to test specifically the
> > combination of win-98 and drives with high cluster-counts.
> > I may have said the tests satisified my interests at the time.
> > I never said that other tests weren't possible.
>
> ONCE AGAIN, **you** verify your tests were incomplete, AND FALSE
> IN NATURE.
Once again, you spew green-house gasses out of your mouth.
You refuse to provide a specific test regimine or protocal. Specific
instructions.
> IN FACT I outlined the basics for you once again.
Basics? Sorry, I'm not going to try and figure out what will satisfy
you and your idea of what constitutes proper tests.
If you don't have the balls or the background to define those tests
explicitly here, to put them down in black and white, then all I'm left
with is just more hot air from you.
Other people are reading this and laughing at you. They can't believe
you're so obtuse. And they don't know why you're not performing these
tests yourself if they're so god-damn important to you.
> SO "shove this where the sun don't shine"....
Your ass?
I can't do that. All the material you're typing here, all of your
so-called wisdom, is coming out of that place at such a pace that I
can't get anywhere near it.
It's like there's this torrent of verbal diarrhea coming from you.
> > Why can't you learn to edit and clean up your posts?
>
> Because moron, I was out here when you were either still in
> diapers, or likely not even born.
What - you can't edit your posts because you're an old fart? Is that
what you're trying to say?
Did you say that you're back in diapers now?
> Shall I describe HOW netiquitte came about,,
No, that's ok. You obviously don't know what it is since you don't
practice it.
> THEREFORE, ALL relevant information should be left within
> ANY post as cutting materials leaves the potential finder
> [via search engine query] with ineffective or
> partial information.
Another load of complete horse shit. A mentally bankrupt reason if I
ever heard one.
We do not type and compose and post messages in usenet for the benefit
of some potential future searcher. We type and compose the post them to
achieve a near-real-time conversation. Anyone searching for these posts
will have enough brains and enough of a facility in front of them to
show them the entire thread. And your reasoning breaks down when
google groups (really, the only usenet search engine in existance at
this point) by default hides quoted material.
> NOW, IF {emphasis} you had half a brain I wouldn't have found
> it necessary to explain this to you for the THIRD time.
Even for the third time it's still a lame-ass and logically
unsupportable reason.
But that's ok. You go on and keep top-posting and full-quoting me in
your replies. I'm sure future searchers will get a laugh out of the
material - at your expense.
Ninety8 Guy
> Petr/MSFN
> LittyX/Lixaanli
> From one of the large drive esdi_506.pdr modifiers:
That information pertains exculsively to issues relating to the
performance and spec's of two replacement options for win-98's native
ESDI_506.PDR driver.
With a functioning replacement for the native driver, any win-98 system
using it will have the potential to be exposed to volumes that exceed
the often quoted 4.177 million clusters (even if the clusters are the
max size of 32 kb).
Nobody in the MSFN forums (in any of the forums) seems to have discussed
the phenomena of what happens when a FAT32 volume exceeds 4.177 million
clusters - except me. Nobody there seems to have posted their own
experience with formatting and running large FAT32 volumes with large
cluster-counts exceeding 4.177 million clusters, or even medium sized
volumes (less than 128 gb) that have more than 4.177 million clusters.
> Recent discussions:
> http://www.msfn.org/board/ ...
>
> I see see 98 Guy posted there with the same UNTESTED materials
> and suggestions... even directing to his supposed posts in this
> group as reference. EXCELLENT way to make fraud seem real.
Yes, and you will notice that nobody in those threads criticized me or
found fault in the material I posted. There are people there who are
very technically minded and knowledgable and who would have posted
rebuttals if there was any valid grounds to find fault in what I posted
or my methods.
Only you are so paranoid about the material I post on this topic. You
claim to be an expert. You claim to know which tests should be
performed, yet you do not come out and explain these tests in sufficient
detail for someone else to actually perform them. Why is that?
Ninety8 Guy
> Well, I took a look at some of your jpgs, and it seems you're
> correct there.
>
> But: I just tried out 2 programs, Partition Magic, and BING
> (BootItNG), and neither one will allow me to create a 76 GB
> partition with 4K clusters. Both programs forced me to use 32 KB
> clusters. In fact, while I was in Partition Magic, I played
> around with that more, by selecting 4K for the cluster size,
> and steadily increasing the partition size, and the max partition
> size I could select was 24.623 GB with 4K clusters, and 49.199 GB
> with 8K clusters. So go figure.
I posted the following in Feb 2007 (this was part of the series of posts
I mentioned earlier in this thread:
----------------------------
5) There is evidence that 6,291,204 clusters may represent some sort
of "magic number". A third-party drive partition tool (PartitionMagic
Pro Server 8.05) resorted to this cluster count when an existing 32 gb
partition was manually resized to 4kb cluster size. Norton Disk
Doctor and Speed Disk was found to work properly using this cluster
count, but not on a volume with a slightly larger cluster count of 7.8
million clusters (see note 7 below). This 6.3 million cluster count,
combined with 32kb cluster size, results in a volume size of 206 gb.
Perhaps this set of parameters is the reason for the 200 gb hard drive
size which emerged in early to mid 2003. A dir command is also
performed instantly with no delays in computing free space given a
volume with 6.3 million clusters.
------------------------------
So yes, I know that some drive formatting tools do have an in-built
limitation when it comes to the number of clusters it will allow when
creating a fat32 volume. In the above case, if using Partition Magic
and setting the cluster size to 4kb, that results in a maximum allowable
volume size of 24.575 gb by my math.
So there are two classes of drive-preparation tools: Those that limit
FAT32 volumes to 6.3 million clusters (regardless of cluster size), and
those that don't. In my experience, many don't. What is so special
about the number 6.3m I don't know. But even so, 6.3 million is still
larger than 4.177 million.
Microsoft's claim that the max number of clusters for a FAT32 drive is
4.177 million is obviously false, and especially in practice under DOS,
win-98 and XP.
MEB
MSFN accepted them because they presumed {wrongly} you had actually done
the tests... had anyone known who you actually are [as we do in this group]
they certainly would have brought you to task over there as well. Moreover,
the most knowledgeable had already moved on, and the matters were being
discussed by third parties {such as yourself} *NOT* the creators of the
large/big drive modifications who likely WOULD have understood potential
issues, both with the format size, intended use, hardware necessities,
system limitations, and other NECESSARY system modifications, which you
ALWAYS ignore.
The tests you continue to claim you know nothing about, WERE explained at
the time they were posted AND as recently as your last series of posts here
{which you, yourself, then referenced within those postings}. As you
constantly post the links to your fraudulent statements regarding your test
results, and the links to those necessary test were placed within those same
discussions BY ME, it is patently clear you are aware of those tests.
DO THE TESTS. As I told you back then, and as recently as your last BS
discussions {and now including this one} on this issue:::
The world WILL embrace your findings IF and ONLY IF *you actually do the
tests and completely finish them*. Otherwise you are doing nothing but
creating yet another "urban myth" and WILL be *personally responsible* for
any parties who have had difficulties, lost data, or any other issues as
might apply due to your non-existent testing and deliberately fraudulent
statements related thereto. IN FACT, should any business or other wish to
personally sue you, they would apparently have just cause. I remind you: YOU
state that no one else has presented these findings EXCEPT YOU, care to
guess why???
--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______
"Ninety8 Guy" <Nin...@Guy.com> wrote in message
news:49E731B4...@Guy.com...
Ninety8 Guy
> MSFN accepted them because ...
MSFN is run by a bunch of extreme weenies who are uber-macroshaft
appologists and sycophants. The only thing that concerns them is when
you talk about anything related to Micro$haft product keys, WGA, WPA,
etc, and to some degree any pointers as to how to obtain or circumvent
license restrictions for any copyrighted product.
Other than that, they really don't care what you post. So if you were
expecting some sort of "official" stamp of approval to be applied to
technical info as it gets posted there, you won't find it.
(more hot air from MEB captured and stored underground)
> The tests you continue to claim you know nothing about, WERE
> explained at the time they were posted AND as recently as your
> last series of posts here
You posted no details. Nothing that could be systematically followed.
> As you constantly post the links to your fraudulent statements
> regarding your test results,
You claim that the material I posted was fraudulent?
You are truely a sick person.
> DO THE TESTS.
POST THE INSTRUCTIONS.
> The world WILL embrace your findings IF and ONLY IF *you
> actually do the tests and completely finish them*.
The world will respect your intellect if you post the details of the
test proceedures.
Bill Blanton
"Ninety8 Guy" <Nin...@Guy.com> wrote in message news:49E6AF57...@Guy.com...
> Bill Blanton wrote:
>
>> > I have found that if a win-98 system is booted into DOS mode,
>> > with himem.sys loaded, that it will easily scan a hard drive
>> > that has a much higher cluster-count than the 4.177 million
>> > claimed by Microsoft as the upper limit for scandisk.
>>
>> Perhaps Microsoft wants to play it safe and assume some will
>> boot a floppy that does not load himem.sys and possibly have
>> scandisk run amok.
>
> But even that is not true.
>
> If I run scandisk without himem.sys, it usually (or always?) refuses to
> run, stating explicitly that it needs himem.sys to be loaded.
I just tried this booting a floppy without loading himem. Scandisk runs on
an 8MB (yea "Mega") volume that has a 1994 cluster count. It
also runs on A:. It won't run on an 8GB volume or a 128GB
volume. Complains about the need for himem.sys. I didn't feel
like looking for the cutoff point, but it may be siginificant. FAT
size vs. memory available to DOS.
None of those drives contained any files (except A:) , so it must be
going by the size (or cluster count)
>> > The largest drive I've tried it on so far had
>> > 120 million clusters.
>>
>> I remember reading some of your posts about this.
>>
>> Just curious,, did you check how much total memory was
>> reported by mem?
>
> You mean system ram?
What's available to DOS.
> I've run it with both 512mb and 1024 mb of ram. Didn't make a
> difference - scandisk (dos version) ran fine either time. I really
> don't think that the entire table(s) are completely loaded or present in
> system RAM at any given moment when scandisk is running, unless perhaps
> if the FAT tables are less than some arbitrarily small size (4 mb? 8
> mb?)
I don't know, but it would be a herculean effort to jump around the FAT
without it completely loaded. Fragged files. Clusters crossing the boundary
of what was loaded. Unloading the data segment, reloading other data,
possibly back and forth, depending.
>> If you did a /surface scan, was the correct number of clusters
>> reported?
>
> In the case of the 500 gb drive with 120 million clusters, I stopped
> scandisk after 24 - 36 hours of continuous running (I projected it would
> have taken 3 days to complete based on it's progress). So no, in that
> case I did not have the opportuning for the scan to be finished before
> being presented the option to do a surface scan. I'm not familiar with
> the /surface option - does that cause scandisk to immediately skip the
> initial file system checks and go straight into the surface scan?
No, it does the normal FAT, Dir, etc. scan and then goes on to the
surface scan.
> But even in that case, chkdsk correctly reported the number of clusters.
>
>> It's probably safe to assume that none of the FAT was above 128GB.
>
> You have to remember that on motherboards that are 48-bit LBA
> compatible, that at the BIOS or DOS level there is no problem with
> drives larger than 128 gb. Basically any motherboard made during or
> after 2002 will have no hard drive size restrictions, and in that
> situation DOS is inherently capable of seeing and properly reading /
> writing to the entire drive.
>
> But Win-98se will have a problem at the 128 gb boundary unless it's
> protected mode driver (ESDI_506.PDR) is replaced with something else.
That's what I was getting at basically. So, DOS doesn't have a problem,
but the native Windows driver does?
>
>> Given that the size of the start and total LBA sector fields
>> in the partition table are 32-bits wide, it's only possible
>> for a basic partition disk (with 512 byte sectors) to be 2TB.
>
> For one thing, it depends on whether or not the sector size on a given
> hard drive is 512 bytes or something larger. I believe it's possible
> that some drives might indeed have 4kb sector size.
That's why I said "(with 512 byte sectors)" I have no idea if 98
can handle drives with 4k sectors. I don't think 4k sector HDDs
are available yet.
> But in any case, the way I understand it, given a sector size of 512
> bytes and a cluster size of 32kb, that FAT32 is limited to 2tb volume
> size and 8tb ultimate hard drive size. Basically 4 volumes of 2tb each
> on an 8tb drive, with each volume having 67 million clusters.
The problem is in the 32-bit LBA sector start field in the partition tables.
32-bits * 512 (sector size) = 2TB.
A partition can't start above that value.
You could conceivably start at 1.99TB, and have a 2TB partition which
would allow for a 3.99TB disk, however there's a lot of 32-bit code that
won't be able to handle the sector count being greater than a dword.
>> Above that you'd have to set it up as a GPT
>> disk. Neither 98 or XP 32-bit support GPT disks.
>
> Hard drive capacity seems to be doubling every 2 years during the past
> decade. In January this year, Western Digital started shipping the
> first 2tb drives. If this rate holds, we should (or could) roughly
> expect to see 8tb drives in 4 years. Plenty of time left to keep using
> FAT32.
Or switch over to exFAT
http://en.wikipedia.org/wiki/ExFAT
http://www.microsoft.com/downloads/details.aspx?FamilyID=1cbe3906-ddd1-4ca2-b727-c2dff5e30f61&displaylang=en
Bill Blanton
> But: I just tried out 2 programs, Partition Magic, and BING (BootItNG), and neither one will allow me to create a 76 GB partition
> with 4K clusters. Both
> programs forced me to use 32 KB clusters. In fact, while I was in Partition
> Magic, I played around with that more, by selecting 4K for the cluster size, and steadily increasing the partition size, and the
> max partition size I could select was 24.623 GB with 4K clusters, and 49.199 GB with 8K clusters. So go figure.
I'll confirm that too :o) .
Just triied with BING as you did. No error message, it just ignored what I
specified. Oh well,, I've never been that concerned with cluster size.
As far as wasting bits..I have more disks than I know what to do with anyway.
Im using some as paperweights.
Bill Blanton
It does go against what MS says. I don't doubt that he created the
drive, but it does need a lot of testing to prove that it's stable. It's
something to play around with, but I wouldn't use do it on a "mission
critical" system or any "casual user" system for that matter.
There's no harm in poking the system to see what it can do.
Ninety8 Guy
> I just tried this booting a floppy without loading himem.
> Scandisk runs on an 8MB (yea "Mega") volume that has a 1994
> cluster count. It also runs on A:. It won't run on an 8GB
> volume or a 128GB volume. Complains about the need for himem.sys.
> I didn't feel like looking for the cutoff point, but it may be
> siginificant. FAT size vs. memory available to DOS.
The point being that scandisk knows when it needs more memory, and it
asks for himem.sys in those situations (if himem is not already loaded).
> I don't know, but it would be a herculean effort to jump around
> the FAT without it completely loaded.
What was the requirement? 4 bytes per cluster?
I guess the only way to test that would be to run a system with a
relatively low amount of ram (say, 32 mb) and see if scandisk will run
on a drive with, say, 16 million clusters - with himem.sys loaded.
> > But Win-98se will have a problem at the 128 gb boundary unless
> > it's protected mode driver (ESDI_506.PDR) is replaced with
> > something else.
>
> That's what I was getting at basically. So, DOS doesn't have a
> problem, but the native Windows driver does?
That's been my experience. Dos uses the BIOS int-13 routines for drive
access. Any motherboard that impliments 48-bit LBA will (or should)
allow for full access of any hard drive that's currently available
(certainly any IDE/PATA drive).
Win-9x had the same problem as the first edition of XP-gold and win-2K
(pre-sp4). They all had protected-mode drivers (drivers that completely
bypassed the bios int-13 functions) and those drivers could not address
sectors beyond the 128 gb point. This has nothing to do with the
cluster size or how the drive is configured from a volume POV.
This was fixed for XP with SP1, and for 2K with SP4 in the 2002
time-frame. Microsoft did not release a fix for win-98se or ME, even
though those OS's were still in their primary support phase.
> That's why I said "(with 512 byte sectors)" I have no idea if 98
> can handle drives with 4k sectors. I don't think 4k sector HDDs
> are available yet.
The discussion and planning for 4kb sector size has been happening in
earnest since at least 2006. Apparently this requires a lot of work for
the various OS's that are (or will be) around in the next 5 years.
The current planning is that there will be some 4kb sector-size drives
available starting 2011.
http://www.tomshardware.com/news/idema-4kb-harddrive-sectors,2520.html
http://www.processor.com/editorial/article.asp?article=articles%2Fp3009%2F06p09%2F06p09.asp
Bill in Co.
> "Bill in Co." <not_rea...@earthlink.net> wrote in message
> news:udX0wZmv...@TK2MSFTNGP02.phx.gbl...
>> But: I just tried out 2 programs, Partition Magic, and BING (BootItNG),
>> and
>> neither one will allow me to create a 76 GB partition with 4K clusters.
>> Both
>> programs forced me to use 32 KB clusters. In fact, while I was in
>> Partition
>> Magic, I played around with that more, by selecting 4K for the cluster
>> size,
>> and steadily increasing the partition size, and the max partition size I
>> could select was 24.623 GB with 4K clusters, and 49.199 GB with 8K
>> clusters.
>> So go figure.
>
> I'll confirm that too :o) .
>
> Just triied with BING as you did. No error message, it just ignored what I
> specified. Oh well,, I've never been that concerned with cluster size.
That's right. No error message. It just ignored it, and used 32 KB
clusters.
MEB
Slack jawed and distinctly mentally challenged Ninety8 Guy spewed:
"Ninety8 Guy" <Nin...@Guy.com> wrote in message
news:49E7C05F...@Guy.com...
> Full-Quoting and Top-Posting Lazy MEB scrawled:
>
> > MSFN accepted them because ...
>
> MSFN is run by a bunch of extreme weenies who are uber-macroshaft
> appologists and sycophants. The only thing that concerns them is when
> you talk about anything related to Micro$haft product keys, WGA, WPA,
> etc, and to some degree any pointers as to how to obtain or circumvent
> license restrictions for any copyrighted product.
HAHAHA, and without their help and ours you would be what ... a cyber
punk...
SO, since you feel you are so much better than they are, point us to YOUR
coding modifications, YOUR 48bit LBA drivers, YOUR WMP conversions, YOUR XP
system modification tweaks, YOUR modified system files required for many
enhanced aspects in any MS OS including 9X; heck point the world to anything
that YOU have actually done ANYWHERE ...
>
> Other than that, they really don't care what you post. So if you were
> expecting some sort of "official" stamp of approval to be applied to
> technical info as it gets posted there, you won't find it.
>
> (more hot air from MEB captured and stored underground)
>
> > The tests you continue to claim you know nothing about, WERE
> > explained at the time they were posted AND as recently as your
> > last series of posts here
>
> You posted no details. Nothing that could be systematically followed.
BS. Moreover, you have never followed anything even remotely related to
systematic. What I defined was for systematic redundant testing of not only
disk structure but system failure issues..
>
> > As you constantly post the links to your fraudulent statements
> > regarding your test results,
>
> You claim that the material I posted was fraudulent?
>
> You are truely a sick person.
It IS fraudulent, you just admitted in this discussion AGAIN, that you did
not finish the tests which you CLAIMED to have performed.. Is it that you
can't even keep track of your own postings, or is it that truth comes from
your fingers, but your mind NEEDS to lie. Seek professional help, they have
distinct treatment procedures for your problem.
>
> > DO THE TESTS.
>
> POST THE INSTRUCTIONS.
You have them saved locally, use them. What happened, lose them? Google is
your friend, search 2006 - 2007 for yourself in this group. In fact I
suggest EVERYONE search for your postings in this group, you have provided
us with LOTS to laugh about since your identities have appeared in here....
and you certainly have wasted lots of MY time...
>
> > The world WILL embrace your findings IF and ONLY IF *you
> > actually do the tests and completely finish them*.
>
> The world will respect your intellect if you post the details of the
> test proceedures.
HAHAHAHAHA, who's world; yours? and purported friends, tsktsk>>, This make
believe world in which you falsely state facts, deliberately mislead
readers, and in which you constantly have to admit *you ARE falsely stating
material fact* when you come to THIS real world.
Like I would wish to live in or be remotely concerned with YOUR world. Keep
your crap out of this forum and you can post any lie you want anywhere you
want, just as you have been doing for a least two years in multiple forums
concerning these supposed tests you NEVER finished, and during which there
was never any individual test attempted for more than two days. AND after
which you IMMEDIATELY installed a stolen XP version to the disk, which you
also bragged about in this forum.
Interesting how both you and Blanton had almost this SAME exact discussion
in 2007, and you posted this crap again in 2008, and now in 2009... hmm
what was it, Using large hard drives in win-98, or was it ....
Ninety8 Guy
> point us to YOUR coding modifications, YOUR 48bit LBA drivers, ...
> system modification tweaks, YOUR modified system files required
> for many enhanced aspects in any MS OS including 9X; heck point
> the world to anything that YOU have actually done ANYWHERE ...
Again we come back to your peculiar facination with my supposed desire
to seek some sort of fame or recognition. You really are one strange
bird. Oh, and by the way, with all those mods, driver re-writes, and
other hacks from the MSFN crowd that you enthusiastically point to,
where are your demands for proof of their stability? Where are your
demands to see test results? Why are you not critical of their work?
Why don't you go there and give them a hard time?
What I've done (running win-9x on a FAT32 drive with many times the
"normal" number of clusters) requires no modified or hacked drivers or
other tweaks. I've done nothing but use the stock win-98 files (with a
couple of win-me files thrown in). Yet you jump all over that,
frothing at the mouth, claiming it can't be done, claiming it can't
possibly work.
> > You posted no details. Nothing that could be systematically
> > followed.
>
> BS. Moreover, you have never followed anything even remotely
> related to systematic.
There has never BEEN anything posted here resembling a systematic test
protocol. And certainly not posted by you.
> What I defined was for systematic redundant testing of not only
> disk structure but system failure issues..
Exactly.
You say you want to see "systematic redundant testing" but you say
absolutely NOTHING about how to go about doing it. You provide no
specific instructions. Are you that dense that you don't understand
this point?
And again, where are your demands for similar "systematic redundant
testing" and investigation of "system failure issues" for the mods,
tweaks and hacks that come out of MSFN?
> It IS fraudulent, you just admitted in this discussion AGAIN,
> that you did not finish the tests which you CLAIMED to have
> performed..
Here is what I said you liar:
------------------
I described exactly what I did to test specifically the combination of
win-98 and drives with high cluster-counts. I may have said the tests
satisified my interests at the time. I never said that other tests
weren't possible.
I never said I wouldn't do any more tests, and I would do more if
someone had something specific in mind. You never described any such
specific test. You just blow hot air and spew generalities.
------------------
Where did I say that I "did not finish tests" that I claimed to have
performed?
> Is it that you can't even keep track of your own postings
No, it's that you can't read. You like to twist what other people say
into a pretzel that resembles the confused thought process inside that
dense head of yours.
> Seek professional help, they have distinct treatment procedures
> for your problem.
You must be an expert on them. You must have had many electro-shock and
lithium treatments over the years. The effects of which can be clearly
seen here.
> > > DO THE TESTS.
> >
> > POST THE INSTRUCTIONS.
>
> You have them saved locally, use them.
I have no such material from you.
Prove to me and to the others reading this that you actually did post
them.
Re-post them right here, right now.
But you won't, because you're a coward who knows full well that you
posted no such instructions. You can't defend what you never posted.
You resort to the same trick you always use when asked a direct
question. Your answer is that you already answered it. You and other
mental midgets of usenet constantly resort to that transparently weak
argument when backed into a corner.
MEB
"Ninety8 Guy" <Nin...@Guy.com> wrote in message
> MEB wrote:
>
> > point us to YOUR coding modifications, YOUR 48bit LBA drivers, ...
>
> > system modification tweaks, YOUR modified system files required
> > for many enhanced aspects in any MS OS including 9X; heck point
> > the world to anything that YOU have actually done ANYWHERE ...
>
> Again we come back to your peculiar facination with my supposed desire
> to seek some sort of fame or recognition. You really are one strange
> bird. Oh, and by the way, with all those mods, driver re-writes, and
> other hacks from the MSFN crowd that you enthusiastically point to,
> where are your demands for proof of their stability? Where are your
> demands to see test results? Why are you not critical of their work?
> Why don't you go there and give them a hard time?
How do you know I wasn't...
Really,,, post your documented results, not just some pics, but actual long
term usage without a secondary OS such as XP;
A. With the full drive as a single partition of 500 gig at 4k clusters.
Show how you can:
1. Use and manipulate a 98 system with a hundred thousand or more base
folders;
2. Create a 100,000 secondaries within each of those 100,000 base folders
with 80,000 or more files therein;
3. Move, copy, edit and otherwise manipulate files and folders in the above
form [meaning a disk filled in that fashion], at the end of the disk
structure.
4. Manipulate [create, edit, move, copy, delete] over 2 gig files with an
unmodified system within that disk structure.
a. Show the tools used to maintain that disk, and verification of how they
functioned.
Post links to pics and other which will validate that you have personally
done this for months, or even weeks and had no issues or problems. Post
links to others who have also accomplished this and posted their results for
cross-verification.
__________
I have ONCE AGAIN, quoted your entire posting for posterity. I hope ALL of
the news groups and forums specifically direct this post as a STICKY post so
all their users can recognize you and what you post, is just a figment of
your imagination and if it deals with anything which you CLAIM to have done,
it is likely based upon fabrications and/or outright lies.. Take specific
NOTICE that this party posted NO LINKS to anything they might have actually
done IN THEIR ENTIRE LIFETIME which might make them worthy of even existing
upon this planet, and instead has indicated that USENET groups, which is one
of the only places this party exists, are considered by this party, as
filled with "mental midgets".
----------
You are so mentally challenged you still haven't realize that you *have*
admitted to the world that *you have lied about your testing, your results,
your abilities, your skills*, your ... well, its easy to say and point out
that you are one of the more dangerous frauds out here, because you don't
care about any harm or damage you might do to other's computers; how
insecure you might make their system; and that to those whom have helped you
grow from that childish poster of 2006 into at least a semi articulate
writer, you have no respect for.... you are seriously mentally
challenged.... writing in a more cohesive form does not mean you have
suddenly become an intellectual giant.