Re: FtDisk device name

OSR_Community_User · August 29, 2001, 10:49am

I figured out that the partition READ/WRITE routine for my disk driver was
not calculating in the starting offset from the start of the disk on
READ/WRITE requests to a partition. That explains alot.

Joe

-----Original Message-----
From: Joe Moriarty [mailto:xxxxx@east.sun.com]
Sent: Monday, July 30, 2001 7:59 AM
To: NT Developers Interest List
Subject: RE: [ntdev] Re: FtDisk device name

Now I have back traced this thing in Win2K as well to find the
difference between Win2K working and WinXp not working. Win2K
does the same thing but with one noticeable difference.

In Win2K, I notice the PartMgr is sitting on top of my Disk’s PDO
partition. The call to FatReadVolumeFile in fastfat.sys does not
succeed until FtDisk is loaded and a request is sent to
//Harddisk/Volume1 which succeeds. So now I see the problem the
questions are.

Why doesn’t the Partition Manager attach to my Disk PDOs in WinXp

Why isn’t FtDisk creating his Device Name in WinXp. The
reason may be related to question 1.

Would calling the Mount Manager as a client from my disk
driver solve this mount problems?

Anyone have any ideas.
Joe

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Joe Moriarty
> Sent: Friday, July 27, 2001 1:48 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: FtDisk device name
>
>
> Actually the answer to the problem is in the fastfat.sys
driver. For some
> reason, the fastfat.sys driver is reading the MBR table and not
> partition 0
> from the harddrive. Same piece of code I used with Win2K. But now has
> changed for WinXp. Well stepping through the Fat File system
> unleashed this
> piece of wisdom when the file system is reading the partition
> table from the
> hard disk. This snipit of code comes from the function
> FatMountVolume() in
> fastfat.sys.
>
>
> > //
> > // Ping the volume with a partition query to make Jeff happy.
> > //
> >
> > {
> > PARTITION_INFORMATION PartitionInformation;
> >
> > (VOID) FatPerformDevIoCtrl( IrpContext,
> > IOCTL_DISK_GET_PARTITION_INFO,
> > TargetDeviceObject,
> > &PartitionInformation,
> > sizeof(PARTITION_INFORMATION),
> > FALSE,
> > TRUE,
> > &Iosb );
> > }
> >
> > //
> > // Make sure we can wait.
> > //
> >
> > SetFlag(IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT);
> >
> > //
> > // Initialize the Bcbs and our final state so that the termination
> > // handlers will know what to free or unpin
> > //
> >
> > BootBcb = NULL;
> > DirentBcb = NULL;
> >
> > Vcb = NULL;
> > VolDo = NULL;
> > MountNewVolume = FALSE;
> >
> > try {
> >
> > BOOLEAN DoARemount = FALSE;
> >
> > PVCB OldVcb;
> > PVPB OldVpb;
> >
> > //
> > // Synchronize with FatCheckForDismount(), which
> > modifies the vpb.
> > //
> >
> > (VOID)FatAcquireExclusiveGlobal( IrpContext );
> >
> > //
> > // Create a new volume device object. This will have the Vcb
> > // hanging off of its end, and set its alignment requirement
> > // from the device we talk to.
> > //
> >
> > if (!NT_SUCCESS(Status = IoCreateDevice( FatData.DriverObject,
> >
> > sizeof(VOLUME_DEVICE_OBJECT) - sizeof(DEVICE_OBJECT),
> > NULL,
> >
> > FILE_DEVICE_DISK_FILE_SYSTEM,
> > 0,
> > FALSE,
> > (PDEVICE_OBJECT
> > *)&VolDo)))
> > {
> >
> > try_return( Status );
> > }
> >
> > #ifdef PNP_POWER
> > //
> > // This driver doesn’t talk directly to a device, and (at the
> > moment)
> > // isn’t otherwise concerned about power management.
> > //
> >
> > VolDo->DeviceObject.DeviceObjectExtension->PowerControlNeeded =
> > FALSE;
> > #endif
> >
> > //
> > // Our alignment requirement is the larger of the processor
> > alignment requirement
> > // already in the volume device object and that in the
> > TargetDeviceObject
> > //
> >
> > if (TargetDeviceObject->AlignmentRequirement >
> > VolDo->DeviceObject.AlignmentRequirement) {
> >
> > VolDo->DeviceObject.AlignmentRequirement =
> > TargetDeviceObject->AlignmentRequirement;
> > }
> >
> > //
> > // Initialize the overflow queue for the volume
> > //
> >
> > VolDo->OverflowQueueCount = 0;
> > InitializeListHead( &VolDo->OverflowQueue );
> >
> > VolDo->PostedRequestCount = 0;
> > KeInitializeSpinLock( &VolDo->OverflowQueueSpinLock );
> >
> > //
> > // Indicate that this device object is now completely
> initialized
> > //
> >
> > ClearFlag(VolDo->DeviceObject.Flags, DO_DEVICE_INITIALIZING);
> >
> > //
> > // Now Before we can initialize the Vcb we need to set up the
> > device
> > // object field in the Vpb to point to our new volume device
> > object.
> > // This is needed when we create the virtual volume file’s file
> > object
> > // in initialize vcb.
> > //
> >
> > Vpb->DeviceObject = (PDEVICE_OBJECT)VolDo;
> >
> > //
> > // If the real device needs verification, temporarily clear the
> > // field.
> > //
> >
> > RealDevice = Vpb->RealDevice;
> >
> > if ( FlagOn(RealDevice->Flags, DO_VERIFY_VOLUME) ) {
> >
> > ClearFlag(RealDevice->Flags, DO_VERIFY_VOLUME);
> >
> > WeClearedVerifyRequiredBit = TRUE;
> > }
> >
> > //
> > // Initialize the new vcb
> > //
> >
> > FatInitializeVcb( IrpContext, &VolDo->Vcb,
> > TargetDeviceObject, Vpb);
> >
> > //
> > // Get a reference to the Vcb hanging off the end of the device
> > object
> > //
> >
> > Vcb = &VolDo->Vcb;
> >
> > //
> > // We must initialize the stack size in our device
> object before
> > // the following reads, because the I/O system has not
> > done it yet.
> > //
> >
> > Vpb->DeviceObject->StackSize =
> > (CCHAR)(TargetDeviceObject->StackSize
> > + 1);
> >
> > //
> > // Read in the boot sector, and have the read be the
> minumum size
> > // needed. We know we can wait.
> > //
> >
> > FatReadVolumeFile( IrpContext,
> > Vcb,
> > 0, // Starting Byte
> > sizeof(PACKED_BOOT_SECTOR),
> > &BootBcb,
> > (PVOID *)&BootSector );
> >
> > //
> > // Call a routine to check the boot sector to see if it is fat
> > //
> >
> > if (!FatIsBootSectorFat( BootSector )) {
> >
> > DebugTrace(0, Dbg, “Not a Fat Volume\n”, 0);
> >
> > //
> > // Complete the request and return to our caller
> > //
> >
> > try_return( Status = STATUS_UNRECOGNIZED_VOLUME );
> > }
> > << snipit of code end >>
> >
> > The TargetDeviceObject is the Device Object of the Disk and not
> > partition0.
> > Notice the call to FatReadVolume File above. The Starting Byte
> > is 0. When
> > your reading from
> > Starting Offset of 0 from the Hard Disk your reading in the MBR. Now
> > dependent on the length you could be reading in the partition tables as
> > well. But, if you look at FatIsBootSectorFat. This function
> > wants the BootSector to be a partition entry. So my problem
> > comes from the
> > fact that the fastfat.sys
> > driver is reading my MBR table and seeing if it’s a fat
> > partition. This is
> > not going to happen. If the code would read the partition0
> entry and find
> > out if it’s a fat partition, then I would have no problems.
> >
> > One of two reasons of what could be wrong. The
> > TargetDeviceObject is wrong.
> > It should point to my Partition Device Object. I find that hard
> > to believe
> > because the call to read the data is still coming from start
> > offset 0. This
> > could be possible if the cache manager understands this and adjusts the
> > offset to read from partition0.
> >
> > The second reason of what could be wrong. The Start Offset in
> the call to
> > FatReadVolumeFile should be
> > calculated to point to partition0 entry.
> >
> > Am I looking at a bug here?
> >
> > Joe
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Peter Viscarola
> > > Sent: Thursday, July 26, 2001 7:45 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: FtDisk device name
> > >
> > >
> > > “Joe Moriarty” wrote in message
> > > news:xxxxx@ntdev…
> > > >
> > > > Problem is, the DDK version of WXP would not work on our platform.
> > > >
> > >
> > > Eh? So, you’re building a driver for XP, but you’re NOT using
> > the Windows
> > > XP DDK? Also, if you’re running Win2K or WinXP, the XP DDK
> > > better work on
> > > your platform… unless you’ve got a totally unsupported
> > setup… in which
> > > case all bets are off in any case.
> > >
> > > I’d do precisely what Mark suggested: Build the disk class
> > driver from the
> > > sources on the DDK and walk into the code. You’re answer will
> > be there in
> > > front of you.
> > >
> > > Peter
> > > OSR
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@east.sun.com
> > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@east.sun.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com