A filesystem's dependence on the size of the volume

NTFSD
1

Question for you file system people:

If I have file system (FAT32 or NTFS) on a volume and I copy (i.e. a
byte-by-byte at the cluster level) all the data in the filesystem to a new
volume which is larger (e.g. contains more clusters) than the original
volume then will the filesystem be able to use all the new clusters within
the new volume? (or will it be limited to the original cluster count?)

That is, will there be a dependence within the filesystem structures of the
original volume size when the volume is created (i.e. formatted). If this
is the case then can you give an example of a structure that would need
‘re-touching?’

Thanks for any insight.

2

The filesystem will be limited to the original cluster count because on
FAT32 it’s necessary to enlarge file allocation table (it has as much
records as much clusters is available) and on NTFS I guess it’s necessary to
enlarge $bitmap (references all available clusters) and probably $mft. Also
in both cases you’ll need to modify BPB (boot sector) which contains
information about amount of clusters available on a volume.

There is the following code:
FSCTL_EXTEND_VOLUME
which might be useful for your purposes (I didn’t work with it though)

Also I had a problem that after copying the system disk (on the file level)
to a new volume which is larger the OS (Win2k, WinXP) didn’t let to login. I
suppose that OS contains records about size of the volume it was installed
on. Probably the mentioned above FSCTL_ will fix the issue.

“Fred Walters” wrote in message news:xxxxx@ntfsd…
> Question for you file system people:
>
> If I have file system (FAT32 or NTFS) on a volume and I copy (i.e. a
> byte-by-byte at the cluster level) all the data in the filesystem to a new
> volume which is larger (e.g. contains more clusters) than the original
> volume then will the filesystem be able to use all the new clusters within
> the new volume? (or will it be limited to the original cluster count?)
>
> That is, will there be a dependence within the filesystem structures of
the
> original volume size when the volume is created (i.e. formatted). If this
> is the case then can you give an example of a structure that would need
> ‘re-touching?’
>
> Thanks for any insight.
>
>
>

3

> If I have file system (FAT32 or NTFS) on a volume and I copy (i.e. a

byte-by-byte at the cluster level)

OK, at raw disk sector level.

the new volume? (or will it be limited to the original cluster count?)

Will be limited. You will need to resize it. NTFS allows this easily, FAT -
only with the help of the 3rd party tools (PowerQuest/Symantec and so).

is the case then can you give an example of a structure that would need
‘re-touching?’

You will need to grow the FAT table for a FAT filesystem, for instance.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

4

> There is the following code:

FSCTL_EXTEND_VOLUME
which might be useful for your purposes (I didn’t work with it though)

NTFS-only IIRC.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

5

> Also I had a problem that after copying the system disk (on the file

level)
to a new volume which is larger the OS (Win2k, WinXP) didn’t let to login.
I
suppose that OS contains records about size of the volume it was installed
on.

This normally happens when you copy the system volume
to another HDD configuration (another partition order or size).
To make the system working, you have to remove all entries from
HKEY_LOCAL_MACHINE\System\MountedDevices
In my experiments, this usually fixed the deadlock in login phase.

But sometimes, the system bugchecked at boot phase
with “INVALID_SYSTEM_CONFIG” or something like that.
Booting to safe mode helped.

L.

6

Thanks a lot

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> > Also I had a problem that after copying the system disk (on the file
> > level)
> > to a new volume which is larger the OS (Win2k, WinXP) didn’t let to
login.
> > I
> > suppose that OS contains records about size of the volume it was
installed
> > on.
>
> This normally happens when you copy the system volume
> to another HDD configuration (another partition order or size).
> To make the system working, you have to remove all entries from
> HKEY_LOCAL_MACHINE\System\MountedDevices
> In my experiments, this usually fixed the deadlock in login phase.
>
> But sometimes, the system bugchecked at boot phase
> with “INVALID_SYSTEM_CONFIG” or something like that.
> Booting to safe mode helped.
>
> L.
>
>