Changing file formats
Steve Hayes
Is it possible to make a similar change from FAT32 to NTFS?
If so, how?
--
Steve Hayes from Tshwane, South Africa
Web: http://hayesfam.bravehost.com/stevesig.htm
Blog: http://methodius.blogspot.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
DL
"Steve Hayes" <haye...@hotmail.com> wrote in message
news:fdl1i51vn4p00apa9...@4ax.com...
Shenan Stanley
> There used to be the option of changing files from FAT16 to FAT32
> on the fly.
>
> Is it possible to make a similar change from FAT32 to NTFS?
>
> If so, how?
Files are not file systems.
Which do you actually mean?
You can change which file system a file is stored on simply by
moving/copying a file from one partition to another partition (if the
partitions are of a different type and will allow the file size, etc to be
placed on it - possibly losing some variables along the way.)
In other words - moving a file from an NTFS to a FAT32 partition will work
fine as long as the file meets the criteria for FAT32 storage (less than 4GB
in size is a big one) and you do not expect it to maintain the NTFS
file/folder permissions. The reverse is easier - since NTFS doesn't have
the file size limitations that FAT32 does and you are adding, not removing,
information to the file (file permissions.)
Now - if you meant file system from FAT32 to NTFS...
Start button --> RUN --> type in:
cmd /k convert /?
--> Click OK.
That will bring up a command prompt with the help information for the
"convert" command in it.
--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html
Steve Hayes
wrote:
Eventually I discovered it wasn't in the menus, or in the help files, but
after some Googling discovered that running config.exe from the command line
did the trick.
Shenan Stanley
Steve Hayes wrote:
> Eventually I discovered it wasn't in the menus, or in the help
> files, but after some Googling discovered that running config.exe
> from the command line did the trick.
Uhm...
CONFIG.EXE?
What is that? AFAIK - that is not native to Windows XP.
Steve Hayes
wrote:
><snipped>
>
>Steve Hayes wrote:
>> Eventually I discovered it wasn't in the menus, or in the help
>> files, but after some Googling discovered that running config.exe
>> from the command line did the trick.
>
>Uhm...
>
>CONFIG.EXE?
>
>What is that? AFAIK - that is not native to Windows XP.
Sorry, should have been CONVERT.EXE
I did it and it worked.
John John - MVP
Steve Hayes wrote:
> On Thu, 10 Dec 2009 09:38:48 -0600, "Shenan Stanley" <newsh...@gmail.com>
> wrote:
>
>> <snipped>
>>
>> Steve Hayes wrote:
>>> Eventually I discovered it wasn't in the menus, or in the help
>>> files, but after some Googling discovered that running config.exe
>>> from the command line did the trick.
>> Uhm...
>>
>> CONFIG.EXE?
>>
>> What is that? AFAIK - that is not native to Windows XP.
>
> Sorry, should have been CONVERT.EXE
>
> I did it and it worked.
Did you run this on a FAT32 drive prepared (formated) by Windows XP? Or
was the drive prepared by another operating system? Is this your
Windows drive or is it a storage drive?
Run this command at a command prompt:
fsutil fsinfo ntfsinfo c:
Use the proper drive letter, in the above command you will get the
information about NTFS on drive C:
In the information given by the command look at the "Bytes Per Cluster"
field and hope that it tells you that the clusters are 4096 bytes. If
they are 512 bytes you may have performance problems with the drive.
John
Steve Hayes
wrote:
>Steve Hayes wrote:
>> Sorry, should have been CONVERT.EXE
>>
>> I did it and it worked.
>
>Did you run this on a FAT32 drive prepared (formated) by Windows XP? Or
>was the drive prepared by another operating system? Is this your
>Windows drive or is it a storage drive?
>
>Run this command at a command prompt:
>
>fsutil fsinfo ntfsinfo c:
>
>Use the proper drive letter, in the above command you will get the
>information about NTFS on drive C:
>
>In the information given by the command look at the "Bytes Per Cluster"
>field and hope that it tells you that the clusters are 4096 bytes. If
>they are 512 bytes you may have performance problems with the drive.
Thanks for that.
I did it on one of the drives I converted and got this:
NTFS Volume Serial Number : 0x6e24e16c24e1382b
Version : 3.1
Number Sectors : 0x000000000c9fd340
Total Clusters : 0x000000000c9fd340
Free Clusters : 0x000000000bbb7d65
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Cluster : 512
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 2
Mft Valid Data Length : 0x00000000082b8000
Mft Start Lcn : 0x000000000095b5ae
Mft2 Start Lcn : 0x0000000004f2b8af
Mft Zone Start : 0x00000000014f4640
Mft Zone End : 0x0000000002df2b80
But performance seems much improved over FAT32.
I had 2 hard Drives on my computer. 0 (C:) was 30 GB and 1 was 40GB,
partitioned into D:, E:, F: and G:. It was about 9 years old, and began to
behave erratically. I bought a new 500 GB drive, and partitioned it in the
same way, but with bigger partitions, restored the backups to it. But FAT32
wastes space on bigger partitions -- on the E: drive listed above it was 32K
bytes per sector, so I converted them to NTFS. The existing data on the E:
drive listed above shrunk from about 10 GB to 7 GB on conversion, and the
programs seem to run faster.
John John - MVP
In my opinion you have a mess on your hands. The 512 byte clusters may
lead to excessive fragmentation which will lead to increased disk I/O
which will in turn lead to a less performing hard disk. The hard disk
is the 'weakest link' in your system's performance, making it weaker
than it already is is not very helpful to the overall performance of
your system.
512 byte clusters might be acceptable if all or most of your files were
512 bytes or smaller, for anything else this is usually a terrible
cluster size. Note that the MFT file record segments are always 1024
bytes and that files of 1KB or less in size are stored in the MFT. Now
with your 512 byte clusters you have the added possibility of internal
fragmentation of the file record segments and this may lead to increased
disk i/o when reading the MFT or when accessing small files stored
within the MFT. In no uncertain terms this will be detrimental to the
performance of the file system. Admittedly on a storage volume where
few files are 1KB or less the fragmentation of the file record segments
may not be important but the increased disk fragmentation caused by the
smaller clusters will still be a constant concern, personally I would
not accept this on any of my drives.
To properly fix this you have little choice but to move the files off
the drive and then format the drive anew. Some third party disk
partitioning utilities profess their ability to resize clusters but I do
not use or recommend the use of these tools for this purpose. Opinions
will vary and others may have different views on the reliability of
cluster resizing by these other utilities.
John
Steve Hayes
wrote:
>
>Steve Hayes wrote:
>> I did it on one of the drives I converted and got this:
>>
>> NTFS Volume Serial Number : 0x6e24e16c24e1382b
>> Version : 3.1
>> Number Sectors : 0x000000000c9fd340
>> Total Clusters : 0x000000000c9fd340
>> Free Clusters : 0x000000000bbb7d65
>> Total Reserved : 0x0000000000000000
>> Bytes Per Sector : 512
>> Bytes Per Cluster : 512
>> Bytes Per FileRecord Segment : 1024
>> But performance seems much improved over FAT32.
>>
>> I had 2 hard Drives on my computer. 0 (C:) was 30 GB and 1 was 40GB,
>> partitioned into D:, E:, F: and G:. It was about 9 years old, and began to
>> behave erratically. I bought a new 500 GB drive, and partitioned it in the
>> same way, but with bigger partitions, restored the backups to it. But FAT32
>> wastes space on bigger partitions -- on the E: drive listed above it was 32K
>> bytes per sector, so I converted them to NTFS. The existing data on the E:
>> drive listed above shrunk from about 10 GB to 7 GB on conversion, and the
>> programs seem to run faster.
>
>In my opinion you have a mess on your hands. The 512 byte clusters may
>lead to excessive fragmentation which will lead to increased disk I/O
>which will in turn lead to a less performing hard disk. The hard disk
>is the 'weakest link' in your system's performance, making it weaker
>than it already is is not very helpful to the overall performance of
>your system.
Well, as I said, it seems a considerable improvement in performance over FAT32
with 32K clusters, and on one logical drive shrunk the space used from 10.5 GB
to just over 7 GB.
And that was the result produced by CONVERT.EXE.
>
>512 byte clusters might be acceptable if all or most of your files were
>512 bytes or smaller, for anything else this is usually a terrible
>cluster size. Note that the MFT file record segments are always 1024
>bytes and that files of 1KB or less in size are stored in the MFT. Now
>with your 512 byte clusters you have the added possibility of internal
>fragmentation of the file record segments and this may lead to increased
>disk i/o when reading the MFT or when accessing small files stored
>within the MFT. In no uncertain terms this will be detrimental to the
>performance of the file system. Admittedly on a storage volume where
>few files are 1KB or less the fragmentation of the file record segments
>may not be important but the increased disk fragmentation caused by the
>smaller clusters will still be a constant concern, personally I would
>not accept this on any of my drives.
I suppose I'll just have to check for fragmentation, and do a defrag if
necessary.
>To properly fix this you have little choice but to move the files off
>the drive and then format the drive anew. Some third party disk
>partitioning utilities profess their ability to resize clusters but I do
>not use or recommend the use of these tools for this purpose. Opinions
>will vary and others may have different views on the reliability of
>cluster resizing by these other utilities.
I suspect that if I restored my backups, it would just restore them with the
original cluster size from the disk image. I used Acronis to backup and
restore the files in each partition on to the new drive.
John John - MVP
> Well, as I said, it seems a considerable improvement in performance over FAT32
> with 32K clusters, and on one logical drive shrunk the space used from 10.5 GB
> to just over 7 GB.
I'm not surprised that you find an improvement over FAT32, regardless of
the cluster size in many regards NTFS performs much better than FAT32
and it is less wasteful on disk space, especially with 512 byte clusters!
> And that was the result produced by CONVERT.EXE.
Yes, I know. This is a very well known issue on the older NT operating
systems or on Windows XP when the drive was formatted with older Windows
9x versions or with third party utilities. Had the drive been formatted
FAT32 by Windows XP the drive would have been automatically aligned on a
4K boundary and the NTFS convert would have yielded 4K clusters. When
the FAT32 drive is prepared by older Windows operating systems or by
third party utilities it may not necessarily be aligned to a 4K boundary
and the convert will yield the 512 byte clusters. You can take steps to
align the partition before converting to NTFS, but it's too late now,
you can't undo the conversion to 512 byte clusters. Read here for a
complete explanation:
http://www.aumha.org/win5/a/ntfscvt.php
Converting FAT32 to NTFS in Windows XP
>> 512 byte clusters might be acceptable if all or most of your files were
>> 512 bytes or smaller, for anything else this is usually a terrible
>> cluster size. Note that the MFT file record segments are always 1024
>> bytes and that files of 1KB or less in size are stored in the MFT. Now
>> with your 512 byte clusters you have the added possibility of internal
>> fragmentation of the file record segments and this may lead to increased
>> disk i/o when reading the MFT or when accessing small files stored
>> within the MFT. In no uncertain terms this will be detrimental to the
>> performance of the file system. Admittedly on a storage volume where
>> few files are 1KB or less the fragmentation of the file record segments
>> may not be important but the increased disk fragmentation caused by the
>> smaller clusters will still be a constant concern, personally I would
>> not accept this on any of my drives.
>
> I suppose I'll just have to check for fragmentation, and do a defrag if
> necessary.
Wait until you run into problems that require a chkdsk on the drive and
see how well it runs if it has to run all over the disk for fragmented
file record segments...
>> To properly fix this you have little choice but to move the files off
>> the drive and then format the drive anew. Some third party disk
>> partitioning utilities profess their ability to resize clusters but I do
>> not use or recommend the use of these tools for this purpose. Opinions
>> will vary and others may have different views on the reliability of
>> cluster resizing by these other utilities.
>
> I suspect that if I restored my backups, it would just restore them with the
> original cluster size from the disk image. I used Acronis to backup and
> restore the files in each partition on to the new drive.
Backups will not change cluster size, the cluster size is fixed. This
is the same as the file system, you can restore a backup of files from a
FAT32 volume to an NTFS volume and it will not affect the file system
format, the volume will remain NTFS and the files will be just fine.
You can also restore files backed up from an NTFS volume to a FAT32
drive and providing that the files are smaller than 4GB you will be able
to restore them to the FAT32 drive without problems, this will not
affect the FAT32 file system but the files would be stripped of their
NTFS metadata because FAT32 has no way of storing NTFS attributes. This
means that the details about things like file ownership and access
rights and that data streams and so on will be lost when you restore
files from an NTFS volume to a FAT32 drive, but the files themselves
will be perfectly fine, backups are not concerned with cluster sizes or
with the file system structure.
If you clone or image the drive then this is a different story, the file
system structure is also cloned or imaged and when you restore a disk
image the file structure is also restored. In a case like yours the
user can fix his file system and the cluster size then create new images.
John