Fat32 to NTFS issue(s)?

Recently I installed Windows XP onto my system (it already had Win98SE) on it.... as I did not want to wipe out Win98SE, I installed XP to drive D:, which seemed to work fine(and lets me choose between XP and 98SE), since most games worked I've decided to use XP as my primary gaming OS, now for the but part: I converted drive D: from FAT32 to NTFS (it was a very large partition, close to 200GB) and I have quasi-memory that FAT32 starts to misbehave aftwer a while on such a large partition, but now I have read that converting a partition from FAT32 to NTFS can introduce all sorts of headaches too.... so this is what I would like to do: copy the files and such from drive D to another drive, then format drive D (as NTFS) and then copy the files back.... note that an imaging tool will maintain any misinformation of the partition so an imaging tool is out of the question... can this work? (I ask because if XP was on drive C: it would no do to MBR stuff, but it is on drive D
I started to gets lots of BSOD recently, and I am not too sure what it is caused by, could be my (new) WLAN or that I installed a new game recently and drive D: is starting to get full, so the game's data and executable are subtly corrupted on the drive due to a "bad" FAT32->NTFS conversion.

 

I used the XP (or windows 2000, can't remember which) utility to convert the partition to NTFS... chances are the cluster size is 512bytes (how do you check what the cluster size is?)

the BSOD's vary, a common theme: "Windows shutdown the computer to prevent damage" but the named files that "cause" the fault vary... sometimes a file is not even named... my fear is that the FAT32 partition was corrupted somewhat (via Win98SE crashes) before I converted it and such corruptions were not fixed in the conversion to NTFS...

I also would not mind getting the cluster size to be 4KB to get better speed...

my simple plans were this: boot up Windows2000, copy my drive D: to another harddrive, repartition drive d, format the new parition as NTFS then copy the stuff back... I have 2 drives in my system, the first drive has serveral partitions, FAT32 (for win98SE, C: ), NTFS (Windows2000, E: ) and the rest are for Linux (swap, boot, home, OS) and the 2nd drive is just one big partition, D:.... both drives are master (i.e. first drive is primary master and 2nd drive is secondary master).

I am hoping to not need to reinstall winXP (admittedly I can export the registry setting for the games and apps so I don't really have to reinstall them, but it is such a hassle to reinstall an OS not to mention have to get the OS up to date again, ect)

naturally one can say: if the files are corrupted this won't fix the problem really anyways since the copying will copy corrupted files.... but I am thinking (hoping) that perhaps the issues only come to a head when I start to fill up towards the end of the drive... in particular, wherever windows decides to put the swap space on the drive

 

The 512kb byte cluster size and boundary alignment issues arose during XP beta releases using CONVERT.EXE from Windows 2000.

CONVERT.EXE uses 4k clusters, and has no boundary issues.

http://www.microsoft.com/whdc/system/winpreinst/ntfs-preinstall.mspx

 

The article I cited earlier discusses the issue of an already FAT32 formatted Volume:

 

well, looking with windows XP's defragmentor I see that the cluster size is 512 bytes....

however, I have not seen anyone reply to my initial idea/post: copy the data onto another driver, repartition and reformat and then copy back. Will this work? I was hoping thinking it would since the drive XP is on is NOT the boot drive anyways so the MBR of the boot drive is untouched and such... anyone know if my plans will work or backfire?

 

Cluster size is not exposed in the GUI.

Here is the analysis report from a Volume that was formatted FAT32 under Win98SE and a convert.exe operation to NTFS done under XP :

Code:

C:\WINDOWS\system32>defrag /?
Usage:
defrag <volume> [-a] [-f] [-v] [-?]
  volume  drive letter or mount point (d: or d:\vol\mountpoint)
  -a      Analyze only
  -f      Force defragmentation even if free space is low
  -v      Verbose output
  -?      Display this help text

C:\WINDOWS\system32>defrag d: -a
Windows Disk Defragmenter
Copyright (c) 2001 Microsoft Corp. and Executive Software International, Inc.

Analysis Report
    76.33 GB Total,  46.76 GB (61%) Free,  0% Fragmented (0% file fragmentation)


You do not need to defragment this volume.


C:\WINDOWS\system32>defrag d: -a -v
Windows Disk Defragmenter
Copyright (c) 2001 Microsoft Corp. and Executive Software International, Inc.

Analysis Report

    Volume size                         = 76.33 GB
    Cluster size                        = 4 KB
    Used space                          = 29.57 GB
    Free space                          = 46.76 GB
    Percent free space                  = 61 %

Volume fragmentation
    Total fragmentation                 = 0 %
    File fragmentation                  = 0 %
    Free space fragmentation            = 0 %

File fragmentation
    Total files                         = 17,163
    Average file size                   = 2 MB
    Total fragmented files              = 1
    Total excess fragments              = 18
    Average fragments per file          = 1.00

Pagefile fragmentation
    Pagefile size                       = 1.46 GB
    Total fragments                     = 1

Folder fragmentation
    Total folders                       = 2,181
    Fragmented folders                  = 1
    Excess folder fragments             = 0

Master File Table (MFT) fragmentation
    Total MFT size                      = 29 MB
    MFT record count                    = 19,368
    Percent MFT in use                  = 64
    Total MFT fragments                 = 2

You do not need to defragment this volume.

 

I have no idea what role the MBR could possibly play with your manipulation of Drive D.

You should not be surprised, however, if you are asked to re-activate your copy of XP because of the erasure of your Volume ID on the drive with the format.

That is the only "gotcha" I can think of. Even in that instance you could replace the Volume ID post-format with the original (write it down prior to the format) using a Sysinternals/Microsoft utiliity VolumeID: http://www.sysinternals.com/Utilities/VolumeId.html

 

the issue of MBR and such comes to booting the system:

for example, if one were to try the same trick with Windows98SE, one must make sure that the drive was formatted with "format /s ", i.e. copy system files, so that the default MSDOS boot loader works correctly (which is installed via "fdisk /mbr ") however 2000/XP have a real boot loader and are not as dumb as Win9x are, so... but the issue comes up, how does the boot loader hand over execution to windows XP/2000/whatever when one chooses the OS from the choice? Does it use a filename (thus the boot loader understands FAt32/NTFS file systems) or does it assume that the boot loading code is in a very particular place on the drive? if it is the second then just copying the files will not work since the files will not be in the same place....


by the way, I found the cluster size under the GUI by: right click harddrive--> properties --> Tools (tab)--> Deframent now (button) --> Analysze (button) wait, and the hitting View Report (button).

 

As I gather info on FAT32, I have read that it is generally a very bad idea to use have a FAT32 partition with size greater than 32GB... has anyone else seen anything like this? Some web pages give a variable size of the max size for a FAT32 partition (though they do not say how it depends, only that it depends on which incarnation of win9x, i.e. 95, 98, 98SE or Me) moreover, today I just bought an external USB drive and it's manual says tat if you want a partition to be bigger than 32GB, you shoud use NTFS (though it ships formatted FAT32 with the partition in excess of 200GB) go figure....

 

XP normally looks where the boot.ini file directs it to find the file "NTLDR" and proceeds to read the rest of the necessary loader code from that file.

If the boot.ini file is corrupt or missing completely, XP will look for the NTLDR file on the root of the C: drive.

BTW, when I say XP looks for the file I actually mean that the boot loader code string contained in the MBR is really what is directing the process. That makes you realize that the MBR code for XP is different than the MBR code for WinXX. This difference is not a function of the type of file storage (FAT vs. NTFS) but strictly a function of the XP operating system.

HTH

 

And some say if you do use XP to format FAT32 volumes greater than 32gb Microsoft sends black helicopters to circle your home.

XP can format a drive greater than 32gb as FAT32 either during installation or using Disk Manager:

. You can do the format directly:

. You can format NTFS, and CONVERT to FAT32. This approach should of course not be taken for the Boot and System volumes, as the drive contents are lost;

. You can use the native XP Commnad DISKPART.EXE. The command is available both in Recovery Console and under the CMD shell: http://support.microsoft.com/default.aspx?scid=kb;EN-US;300415

 

that is what I hoped, i.e. the boot loader code just contains a string to where boot.ini is, but that string is just a file name, not a specific location on the harddrive right?

as for the 32GB limit for FAT32, I have just read on various sites that above 32GB on FAT32 for some windows OS's is a bad idea, but I have not read any clear reasons as to why... even my external harddrive manula says for FAT32, not more than 32GB (though they format it as FAT32 with a 200+ GB partition).

 

Hi krogue,

You said in your initial post that you had "recently" installed XP to Partition 'D'.
If you have not added too much stuff to 'D' since, why not just re-install XP and select to use NTFS?
Just an idea.

Roger

 

I mis-remembered this switch:
/fs:ntfs

It is not an optional switch if using the convert.exe utility, and I thought there was a FAT32 filestore equivalent.

My apologies.

For diskpart.exe and formatting using Recovery Console or otherwise:

Command line under Recovery console:

DISKPART
diskpart /add /delete device_name drive_name partition_name size
Use this command to manage the partitions on your hard disk volumes. You can use the following options:
/add : Creates a new partition.
/delete : Deletes an existing partition.
device_name : The name of the device that is used to create a new partition.
drive_name : A drive-letter-based name, for example D:.
partition_name : The partition-based name for deleting an existing partition.
size : The size of the new partition in megabytes.

You can determine the device name from the output of the MAP command, for example, \Device\HardDisk0. You can use the partition name instead of the drive name argument, for example, \Device\HardDisk0\Partition1. If you use no arguments, a user interface for managing your partitions appears.


DISKPART used interactively:
Example:

diskpart
select disk 3
select partiton 1
create partition primary [size=n] [noerr]
assign E:
exit

You now have a single partition (if you choose) on drive letter E: that can be formatted under NTFS or FAT32.

Recovery Console: FORMAT

format drive: /Q /FS:file-system

Use this command to format the specified drive to the specified file system. In the command syntax, /Q performs a quick format of the drive, drive is the drive letter of the partition to format, and /FS:file-system specifies the type of file system to use such as FAT, FAT32, or NTFS. If you do not specify a file system, the existing file system format is used if it is available.