I am working on a utility to backup a NTFS volume i.e. only the used part
but with the OS nevertheless. For experimenting, I attempted initially
using FSCTL_GET_VOLUME_BITMAP on a floppy (FAT) to get the cluster reqd.
Subsequently realised that the actual data clusters start at a fixed
offset & that is where cluster #1 begins. This mechanism as such doesn’t
provide information about ‘system’ area of volume/disk.
As such I have 2 queries -
How does one obtain information about the system area of a disk at the
raw level for copying it subsequently?
How is the mechanism different between FAT & NTFS?
Under NTFS, it does contain all of the clusters. FAT is a little different,
but the math is simple. I think Max has a code snippet he may be willing to
share
I am working on a utility to backup a NTFS volume i.e. only the used part
but with the OS nevertheless. For experimenting, I attempted initially
using FSCTL_GET_VOLUME_BITMAP on a floppy (FAT) to get the cluster reqd.
Subsequently realised that the actual data clusters start at a fixed
offset & that is where cluster #1 begins. This mechanism as such doesn’t
provide information about ‘system’ area of volume/disk.
As such I have 2 queries -
How does one obtain information about the system area of a disk at the
raw level for copying it subsequently?
How is the mechanism different between FAT & NTFS?
Thanks Jamey. Does this mean that going exclusively by the bit-map
returned with the assumtion that cluster #1 starts at offset 0 on the
volume should be sufficient?
As I understand it, the partition table may not be within the same volume.
How does one deal with that area?
Have you read the FAT doc from M$? If you do and understand it, then it
becomes simple. NTFS is another problem.
wrote in message news:xxxxx@ntdev… > > Thanks Jamey. Does this mean that going exclusively by the bit-map > returned with the assumtion that cluster #1 starts at offset 0 on the > volume should be sufficient? > > As I understand it, the partition table may not be within the same volume. > How does one deal with that area? > >
Bad idea. Do FAT first and then add NTFS. It is undocumented and much
harder, but the parts of the hard drive outside of the volume are the same.
I hate NTFS and won’t use it until Microsoft documents it on my personal
development system. I use it on server and for testing, but if it is so bad
it isn’t included with the IFS Kit, I don’t want it and some recent
benchmarks say it is slower. If you think using NTFS is good for security -
Security by obscurity is not anything resembling security.
“A. Kaul” wrote in message news:xxxxx@ntdev… > > David - My goal is NTFS only & have been looking at FAT for experimental > purposes. > >
----- Original Message -----
From: “Jamey Kirby” To: “Windows System Software Devs Interest List” Sent: Sunday, December 14, 2003 10:40 PM Subject: [ntdev] RE: ntfs layout
> Under NTFS, it does contain all of the clusters. FAT is a little different, > but the math is simple. I think Max has a code snippet he may be willing to > share > > Jamey Kirby, Windows DDK MVP > StorageCraft Inc. > xxxxx@storagecraft.com > http://www.storagecraft.com > > > > > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@atlanta.nsc.com > Sent: Sunday, December 14, 2003 11:07 AM > To: Windows System Software Devs Interest List > Subject: [ntdev] ntfs layout > > I am working on a utility to backup a NTFS volume i.e. only the used part > - but with the OS nevertheless. For experimenting, I attempted initially > using FSCTL_GET_VOLUME_BITMAP on a floppy (FAT) to get the cluster reqd. > Subsequently realised that the actual data clusters start at a fixed > offset & that is where cluster #1 begins. This mechanism as such doesn’t > provide information about ‘system’ area of volume/disk. > > As such I have 2 queries - > 1. How does one obtain information about the system area of a disk at the > raw level for copying it subsequently? > 2. How is the mechanism different between FAT & NTFS? > > Thanks, > A. Kaul. > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
The first cluster is 2 not zero. It does begin where you said. The first
two entries in the FAT are for clusters zero and one. The media ID byte and
a couple of bits for hard errors encountered and clean shutdown are in those
entries for Fat16 & Fat32. Nothing like it for Fat12, but the entries are
filled with all ones except the media ID. The Fat32 File System
Specification Version 1.03, dated December 6, 2000 is a good source for
understanding FAT. Also good code snippets for formatting and analyzing FAT
partitions. I have been spending a lot of time with it the last few weeks.
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… > > For FAT32, cluster 0 starts just after the FATs > For FAT12/16, it starts just after the root directory. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > > ----- Original Message ----- > From: “Jamey Kirby” > To: “Windows System Software Devs Interest List” > Sent: Sunday, December 14, 2003 10:40 PM > Subject: [ntdev] RE: ntfs layout > > > > Under NTFS, it does contain all of the clusters. FAT is a little different, > > but the math is simple. I think Max has a code snippet he may be willing to > > share > > > > Jamey Kirby, Windows DDK MVP > > StorageCraft Inc. > > xxxxx@storagecraft.com > > http://www.storagecraft.com > > > > > > > > > > > > -----Original Message----- > > From: xxxxx@lists.osr.com > > [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@atlanta.nsc.com > > Sent: Sunday, December 14, 2003 11:07 AM > > To: Windows System Software Devs Interest List > > Subject: [ntdev] ntfs layout > > > > I am working on a utility to backup a NTFS volume i.e. only the used part > > - but with the OS nevertheless. For experimenting, I attempted initially > > using FSCTL_GET_VOLUME_BITMAP on a floppy (FAT) to get the cluster reqd. > > Subsequently realised that the actual data clusters start at a fixed > > offset & that is where cluster #1 begins. This mechanism as such doesn’t > > provide information about ‘system’ area of volume/disk. > > > > As such I have 2 queries - > > 1. How does one obtain information about the system area of a disk at the > > raw level for copying it subsequently? > > 2. How is the mechanism different between FAT & NTFS? > > > > Thanks, > > A. Kaul. > > > > — > > Questions? First check the Kernel Driver FAQ at > > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > >
