Can not format to FAT32???

M

mxh

Bruce Chambers said:
Greetings --

By design, WinXP cannot create and format a new partition greater than
32 Gb. This is because NTFS is the superior file system, and not nearly
as wasteful of drive space. (If you make a FAT32 partition larger than 8
Gb, you're "throwing away" significant amounts of storage capacity.
However, the OS has no problems being installed upon or otherwise using
FAT32 a partition larger than 32 GB, as long as that partition has been
created/formatted by another OS, such as Win98.


Bruce Chambers

Thanks for the response Bruce. I should have deduced that the culprit was
the XP formatter, since I had previously successfully formatted it to 115 gb
in an ME machine. Well, at least I'm finally getting around to checking out
the NTFS file structure, even if inadvertantly.

Thanks again,

Mark
 
M

mxh

Bob Harris said:
A "feature" of XP is that it refuses to make FAT32 partitions greater than
32 Gig. It can use them, but it won't make them.

If you really want a big FAT32 partition, get a third-party like Partition
Magic, version 8.

However, you should ask why you want FAT32, instead of NTFS.
Compatibility
with 98/ME or LINUX would be a good answer. Otherwise, NTFS is a more
robust file system. Further, it can handle very large single files, as
opposed to the 4Gig limit for FAT32. If you do any video procssing, 4Gig
can be too small.

I once thought that it was nearly impossible to recover files from NTFS,
since a DOS boot floppy can't see an NTFS partition. However, these days
there are free NTFS drivers for DOS. These are read-only, but allow
copying
off of the NTFS partition to a FAT32 (or 16 or 12) partition. (Note that
the corresponding write-drivers are available, but not free.) Further,
there are recovery programs that specialize in NTFS. Finally, there are
mini-LINUX distributions that can be run from a CD that can read NTFS and
copy files off of a disk.

Thanks, Bob. Reading from DOS won't really be an issue for this partition,
but if I make the switch to NTFS for other partitions, it may well be.
Thanks for the comments in that regard.

Mark


<snip>
 
M

mxh

Alex Nichol said:
XP will not format any partition bigger than 32GB as FAT 32. You can do
it by getting a Win98 startup floppy (if one is not to hand, download an
image to make one from www.bootdisk.com) and boot it; use its FORMAT
command, making sure that you have the correct drive letter - that may
*not* be the same as the one XP is using for the partition



Thanks, Alex. In the case of the drive letters, I generally change them from
Disk Management to suit my needs anyway.

Mark
 
M

mxh

William Wang said:
Hi Mark,

Thanks for your posting and thanks for the valuable information provided
by
all of you. I'm just checking to see if you need further assistance.
Please
feel free to let us know if you have any questions at any time.

Sincerely,

William Wang
Microsoft Online Support Engineer

Thanks, William.


<snip>
 
C

cquirke (MVP Win9x)

Thanks for all the indepth info. I have been using the "mistakenly" NTFS
formatted partition now for 3 or 4 days (this partition is exclusively for
video) and have not run into any issues. I also like being able to record
files larger than 4gb (except for the fact that I can't copy these across
the network to a FAT32 partition, but that's really not that big of a deal).

Yes, NTFS would be great for big files; even if your video editing
software has a workaround for FAT32's file size limit, you may still
want to prepare large files for writing to DVD.
After reading your comments, I've also DL'ed BING to check it out.

Lovely app, is BING!
but the real question here is, if chkdsk and Scandisk do such a poor job, what
recommendations are there for a third party solution for chkdisk/scandisk?

It's not that they do a poor job; more that what they are doing isn't
what you think they should be doing. What you think they should be
doing - i.e. recovering your data - is too complex a task to be
automated to that extent. Chkdsk, Scandisk, Norton Disk Doctor and
similar tools are designed to maintain the file system in much the
same way that club bouncers are employed to keep the peace.

Just as a bouncer may have to crack heads to get the job done, so it
is that file system repair tools will discard data when they can't
recover it. The biggest risk is when things are so wildly out of
shape that one should rather proceed to data recovery.

For example, if Scandisk were to say "My Documents is invalid.
Delete?" you'd be inclined to back out and copy off your stuff before
running Windows again. If that was ChkDsk /F, it would (if you were
watching) tell you that My Documents had been deleted.

These utils work from one end of the problem to the other, without a
sense of overview. For example, let's say you drop in a HD from one
PC into another that uses a different geometry. Just about every
single directory pointer is going to be misaligned, and as a human
tech, you might think "jeez, this makes no sense at all; maybe the
geometry's wrong here?" But these tools will simply bash away, fixing
one "broken" thing after another until everything is reduced to
rubble. Now the file system's equally trashed no matter what geometry
you use to look at it - and there's no going back.

So my recommendation is to never allow these tools to fix things
automatically, to watch what they do, and make sure you keep a log of
everything they do (even if you can't undo these changes later).


--------------- ----- ---- --- -- - - -
Who is General Failure and
why is he reading my disk?
 
W

William Wang[MSFT]

Hi Mark,

Thanks for your update. Per you response I'm going to consider this issue
Resolved. However, should you have any further questions please feel free
to let us know. We will be glad to work with you.

Sincerely,

William Wang
Microsoft Online Support Engineer

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
M

mxh

cquirke (MVP Win9x) said:
Yes, NTFS would be great for big files; even if your video editing
software has a workaround for FAT32's file size limit, you may still
want to prepare large files for writing to DVD.


Lovely app, is BING!


It's not that they do a poor job; more that what they are doing isn't
what you think they should be doing. What you think they should be
doing - i.e. recovering your data - is too complex a task to be
automated to that extent. Chkdsk, Scandisk, Norton Disk Doctor and
similar tools are designed to maintain the file system in much the
same way that club bouncers are employed to keep the peace.

Just as a bouncer may have to crack heads to get the job done, so it
is that file system repair tools will discard data when they can't
recover it. The biggest risk is when things are so wildly out of
shape that one should rather proceed to data recovery.

For example, if Scandisk were to say "My Documents is invalid.
Delete?" you'd be inclined to back out and copy off your stuff before
running Windows again. If that was ChkDsk /F, it would (if you were
watching) tell you that My Documents had been deleted.

These utils work from one end of the problem to the other, without a
sense of overview. For example, let's say you drop in a HD from one
PC into another that uses a different geometry. Just about every
single directory pointer is going to be misaligned, and as a human
tech, you might think "jeez, this makes no sense at all; maybe the
geometry's wrong here?" But these tools will simply bash away, fixing
one "broken" thing after another until everything is reduced to
rubble. Now the file system's equally trashed no matter what geometry
you use to look at it - and there's no going back.


So my recommendation is to never allow these tools to fix things
automatically, to watch what they do, and make sure you keep a log of
everything they do (even if you can't undo these changes later).

Perhaps I've missed it, but how would one accomplish such a task?
 
C

cquirke (MVP Win9x)

Perhaps I've missed it, but how would one accomplish such a task?

Varies with the OS... for completeness:

Win95xx
- auto-Scandisk controlled by Scandisk.ini
- change logging from Overwrite to Append; else OK
- interactive Scandisk; make sure "automatically fix" is unchecked
- interactive DOS Scandisk; save log, always Append (not Overwrite)
- your log file is C:\Scandisk.log

Win98xx
- auto-Scandisk controlled by Scandisk.ini
- many changes from Fix to Prompt, Delete to Prompt or Save
- interactive Scandisk; make sure "automatically fix" is unchecked
- interactive DOS Scandisk; save log, always Append (not Overwrite)
- your log file is C:\Scandisk.log

WinME
- auto-Scandisk *not* controlled by Scandisk.ini
- set changes with Scandisk's Advanced; then MUST run else lost!
- interactive Scandisk; make sure "automatically fix" is unchecked
- no DOS mode, so Windows always runs first (damages file system?)
- your log file is C:\Scandisk.log

XP FAT32
- auto-Chk either "fix" or disabled; nil else possible (RegEdit)
- no ChkDsk interactive mode exists
- use a Win9x Scandisk instead

XP NTFS
- auto-Chk either "fix" or disabled; nil else possible (RegEdit)
- no ChkDsk interactive mode exists
- additional "autofixing" outside of ChkDsk

See the trend here? Increasingly, you have less control, and the
automatic checking becomes more predatory as MS caters more for OEMs
and reduced support calls and less for user data recovery.


-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
 
M

mxh

cquirke (MVP Win9x) said:
Varies with the OS... for completeness:

Win95xx
- auto-Scandisk controlled by Scandisk.ini
- change logging from Overwrite to Append; else OK
- interactive Scandisk; make sure "automatically fix" is unchecked
- interactive DOS Scandisk; save log, always Append (not Overwrite)
- your log file is C:\Scandisk.log

Win98xx
- auto-Scandisk controlled by Scandisk.ini
- many changes from Fix to Prompt, Delete to Prompt or Save
- interactive Scandisk; make sure "automatically fix" is unchecked
- interactive DOS Scandisk; save log, always Append (not Overwrite)
- your log file is C:\Scandisk.log

WinME
- auto-Scandisk *not* controlled by Scandisk.ini
- set changes with Scandisk's Advanced; then MUST run else lost!
- interactive Scandisk; make sure "automatically fix" is unchecked
- no DOS mode, so Windows always runs first (damages file system?)
- your log file is C:\Scandisk.log

XP FAT32
- auto-Chk either "fix" or disabled; nil else possible (RegEdit)
- no ChkDsk interactive mode exists
- use a Win9x Scandisk instead

XP NTFS
- auto-Chk either "fix" or disabled; nil else possible (RegEdit)
- no ChkDsk interactive mode exists
- additional "autofixing" outside of ChkDsk

See the trend here? Increasingly, you have less control, and the
automatic checking becomes more predatory as MS caters more for OEMs
and reduced support calls and less for user data recovery.

Thanks for your thoroughness. I suppose, at least for NTFS, the best option
is to just look for a third party solution.
 
A

Alex Nichol

mxh said:
Thanks for your thoroughness. I suppose, at least for NTFS, the best option
is to just look for a third party solution.


What it comes down to in the end, is that if data is *really* valuable
you should have a thorough and regular back up system, to backup and
verify, to removable media, kept safely. As Chris said, a couple of
posts back, any automatic tool can only do so much: one that you have in
detailed control may end just finding damage that cannot be cured, and a
clean start from backup is all you can do.

Really now disk sizes have grown so much, there should be a review of
file system design, to a system that contains a real level of
redundancy; for example all clusters in a file should contain forward
and backward links so that the file could be reconstructed without any
file system around, back to a 'master file record', of an NTFS style.
And have there all necessary information to reconstruct its place in the
directory structure.

Such things are possible - one thing about Apple is that the original
designs its file system are developed from had much of this provision
(SOS system of early 80s). I can remember recreating a master catalog
of a small hard disk on an Apple III when the first track had been
zeroed
 
C

cquirke (MVP Win9x)

On Fri, 02 Apr 2004 11:39:32 +0100, Alex Nichol

For me, the take-home was to avoid using NTFS for anything I'd ever
want to see again. Certain malware circumstances may force you to
wipe all NTFS volumes, and by the time you do data recovery, the data
may have been lost due to auto-"fixing", rollback and other cleanup.
What it comes down to in the end, is that if data is *really* valuable
you should have a thorough and regular back up system, to backup and
verify, to removable media, kept safely.

Yep. Everyone says "backup, backup, backup" but I'll bet you very few
would accept the challenge if you said: "I'll pay you per clock time
required to restore, if you let me nuke your system. After all,
everything's backed up, right?"

A backup old enough to pre-date the disaster will lose the most recent
work you did. A backup new enough to contain all your data right up
to the present is likely to have suffered the same fate as live data.
Backup limits but does not eradicate the damage of data loss.
Really now disk sizes have grown so much, there should be a review of
file system design, to a system that contains a real level of
redundancy; for example all clusters in a file should contain forward
and backward links so that the file could be reconstructed without any
file system around, back to a 'master file record', of an NTFS style.

That's how PICK's file system used to work; chained data (which is how
overflowing data from pre-allocated file space is integrated) was held
as a doublke-linked list, with prev and next pointers taking up 12
bytes out of every 512-byte data frame.

Advantages: No head travel between the data and some sort of index,
and as it's "atomic", low chance if disconnection between the data and
how it is linked (e.g. the "lost cluster chain" syndrome).

However, several disadvantages suggest themselves.

First, there's no redundancy to sanity-check and detect anomalies,
unless you parallel the embedded linkage with some sort of external
index - which kills much of the advantage of the approach.

Second, it's very hard to get a bird's-eye-view of such a file system.

Third, the embedded nature of these absolute references will bite you
big time in any context that changes raw location, e.g. imaging,
resizing of volumes and so on.


I built by first data recovery skills on a proprietary non-PC file
system that was FAT-like in design, then learned PICK and DOS 3.3 file
systems and recovery thereof at the same time.

The lack of redundany disadvantage of the embedded link approach was
mitigate by PICK's data design, where rnearly everything is stored in
fields that have both a predictive length value and a delimiter. By
seeing which loose frames had delimiters where the length value
predicted, I was able to repair GFEs (Group Format Errors, or as they
say, "Gone For Ever") but fun it was not.
And have there all necessary information to reconstruct its place in the
directory structure.

Redundancy is the key to error detection ans repair, and capacity and
speed aren't the biggest drawbacks. An increase in critical window
period means that adding redundancy can actually add to fragility.

The choice is either non-redundant atomic storage that has a small or
zero critical window, or non-atomic redundancy that breaks if the
operation is interrupted during the longer critical window.

IOW, do you want a system that "never breaks" or that can be fixed
*when* it breaks? In practice, the former is a chimera, given that
nearly every file requires more than one sector to store it and is
thus inherently non-atomic with a significant critical window. Add
delayed file writes, and you can see that even when everything works,
the "bad exit" effect is still going to eat data.

All transaction rollback can do in such cases is avoid having to wash
up the plates afterwards. The food's entirely gone.
Such things are possible - one thing about Apple is that the original
designs its file system are developed from had much of this provision
(SOS system of early 80s). I can remember recreating a master catalog
of a small hard disk on an Apple III when the first track had been
zeroed

I never did Apple, and that's a pity; it sounds as if their file
system would have been fun to play with :)


-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
 
M

mxh

Alex Nichol said:
What it comes down to in the end, is that if data is *really* valuable
you should have a thorough and regular back up system, to backup and
verify, to removable media, kept safely. As Chris said, a couple of
posts back, any automatic tool can only do so much: one that you have in
detailed control may end just finding damage that cannot be cured, and a
clean start from backup is all you can do.

I have to agree with you, Alex. And I do keep multiple back ups via Drive
Image and Ghost, which provide for single file restores as well as partition
restores, and I also have a separate Data partition that I keep "My
Documents" on, and this gets imaged regularly as well. I suppose it's the
control issues that make me want full control over every aspect. An
impossibility, of course.

Thanks,

Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Partition Size Limit for Fat32 14
Converting from FAT32 to NTFS 3
Formatting FAT32 4
formatting with exfat 5
partitions got messed up. 20
Two CD Drives (D:) & (E:) ?? 19
Your XP mybe a Fat32 13
No FAT or FAT32 access 3

Top