Formatting file systems....
Dan Guisinger
I am trying to format a custom file system partition under Windows NT. I
can't find a safe way to do it under user mode that doesn't have a high
chance of overwriting other data.
Anyone know how I might write a filter driver to attach and write to a
specific partition? How does NT do it? Do they use a similar method or
totally different? (I know how to write a filter driver, its just what do I
attach to for a specific partition?)
Thanks!
-Dan Guisinger
Jamey Kirby
the file systems job.
Dan Guisinger wrote in message <706qbl$f0a$1...@fir.prod.itd.earthlink.net>...
Dan Guisinger
have the Windows NT File System Internals book, so yes, I know what does
what. Its just this:
A file system mounts a volume if it recognizes the structures on it.
If a partition doesn't have them on it, it doesn't get mounted.
From what I have seen in WinNT user mode I/O, you can't access an unmounted
partition.
You can access an entire drive, but I don't want to do that, that is to
risky....
So, I ask again, how does NT format disks? From what I know about Win95,
there is a driver that is responsible for unrecognized partitions, but I
have not found any for NT. So, like I said before, can a filter driver of
sorts handle the format procedure if started from a user mode app? Anybody
ever done this?
-Dan Guisinger
Jamey Kirby <jki...@nospam.mkallc.com> wrote in message
708jpb$q6b$1...@nnrp03.primenet.com...
Mark Roddy
>I know how to write a file system driver. I am asking how to format it. I
>have the Windows NT File System Internals book, so yes, I know what does
>what. Its just this:
>A file system mounts a volume if it recognizes the structures on it.
>If a partition doesn't have them on it, it doesn't get mounted.
>From what I have seen in WinNT user mode I/O, you can't access an unmounted
>partition.
>You can access an entire drive, but I don't want to do that, that is to
>risky....
>
>So, I ask again, how does NT format disks? From what I know about Win95,
>there is a driver that is responsible for unrecognized partitions, but I
>have not found any for NT. So, like I said before, can a filter driver of
>sorts handle the format procedure if started from a user mode app? Anybody
>ever done this?
>
>-Dan Guisinger
>
Well look, 'format' is just a user mode app, and it appears to have no
problem with accessing an unformatted volume and formatting it to
either FAT or NTFS, so I don't think that your statement that 'you
can't access an unmounted partition' is accurate.
The 'raw' filesystem is the filesystem of last resort used when an
application attempts to access a volume that is not recognized by any
other FSD.
I agree with others that a filter driver doesn't sound like the
easiest approach to your problem. I think a user mode app will do the
trick. Just open the partition and start scribbling. This assumes of
course that the physical disk has something like a DOS compatible
partition header on it.
Mark Roddy
Consulting Associate,
OSR Open Systems Resources, Inc.
www.osr.com
Dan Guisinger
so, RAW is like VDEF on Win9x? How do I tell RAW to attach to a particular
partition?
I need to tell it to mount a partition since that doesn't happen
automatically, and the only partitions that are mounted on my computer are
\\.\C and \\.\Z. Also, how would I go about accessing the partition? When
I try accessing those other two partitions directly, I get a invalid file
error. If I use \\.\PhysicalDrive0, I get the whole disk drive, which I
don't want (I don't trust my code to behave).
Thanks!
-Dan Guisinger
Mark Roddy <mro...@wattanuck.mv.com> wrote in message
36289c39...@news.mv.com...
Peter van Sebille
Mounting takes place whenever a DEVICE_OBJECT is opened whose type
is FILE_DEVICE_DISK (I'm not sure if it occurs for other types as
well) and the device was not yet mounted. The registered FSDs are
then called one by one to mount the volume. FSDs will mount the volume
if they recognise the volume according to the semantics of that file
system. Raw (very conveniently) happens to be the last FSD to be called
and raw will _always_ mount the volume no matter what.
Hard disks are represented by a device objects called
\Device\HarddikX\Partition0 (X >=0). The partitions on that disk are
represented by device objects called \Device\HarddikX\PartitionY
(Y >= 1).
Since the WIN32 namespace is "limited" to \??, the WIN32 subsystem sets
up a bunch of symblic links. For each hard disk it creates \??\PhysicalDriveX
(X >= 0) which points to \Device\HardDiskX\Partition0. For partitions
on which a "known" file system resides it creates a drive letter.
The definition of a "known" file system seems to be: when passing the
partition id (as returned in the structures by IOCTL_DISK_GET_DRIVE_LAYOUT)
to IsRecognizedPartition() (defined in in the SDK/DDK), it should return TRUE.
For example, WIN32 does _not_ create a drive letter for partitions on which
a linux file system resides (id = 131).
Also, I have a parallel ZIP drive which creates two device objects:
\Device\HardDisk2\Partition0 and \....\Partition1. When querying the
partition tables on this physical drive using the above mentioned IOTCL,
the partition id for Partition1 is most conventiently always 6 (FAT16 >32MB);
this is irrespective of the actual ZIP that is inserted (which may be a
non-FAT disk! ). Doing so, will cause WIN32 to create a drive letter for it.
So, in order to mount a volume, you either need to open it via its drive
letter or via it's fully qualified device name. Both can be done in WIN32,
the latter by using ntdll.dll's NtCreateFile whose function prototype
is listed in Rajeev Nagar's book.
It is then up to the FSD to support direct access to the physical media
when a volume is mounted. This means synchronising access to the volume
by applications issueing normal file I/O and the application that wants
direct access to the volume. Raw will always allow that since that
its purpose in life. Once you've opened the volume, you can read/write
to it using WIN32 ReadFile/WriteFile in which the FileOffset is actually
the byte offset in the volume.
cheers,
Peter
Jeff Henkels
<362A1312...@yipton.demon.co.uk>...
A quick check of DejaNews on this thread shows that no one else has
brought this up, so I guess I'll do it.
Check out http://www.sysinternals.com/fmifs.htm for information on what
Mark Russinovich calls the Format Manager for IFS; it sounds like it
might be useful.
The upshot is that you should write a utility DLL, such as UFAT.DLL or
UNTFS.DLL, which has knowledge of the disk format -- if you do this, you
can do formatting and chkdsk through Explorer, just as you can for FAT
and NTFS.
For command-line utilities, you should be able to adapt the source
provided on the aforementioned webpage to handle your disk format.
Unfortunately, the page doesn't really tell you much about the
UFAT/UNTFS/UyourFmt DLLs that actually know about the disk formatting --
perhaps that info is in the IFS kit, which I don't have.
Hope this helps.
Andy Lutomirski
Andy Lutomirski
for tips.