Bug in CDROM.SYS

In DDK2000...WDK 5112, CDROM.SYS!CdRomInterpretReadCapacity contains the
following code:

----------------------------
//
// Calculate media capacity in bytes.
//
commonExtension->PartitionLength.QuadPart = (LONGLONG)(lastSector + 1);

//
// we've defaulted to 32/64 forever. don't want to change this now...
//

fdoExtension->DiskGeometry.TracksPerCylinder = 0x40;
fdoExtension->DiskGeometry.SectorsPerTrack = 0x20;

//
// Calculate number of cylinders.
//

fdoExtension->DiskGeometry.Cylinders.QuadPart = (LONGLONG)((lastSector +
1) / (32 * 64));

commonExtension->PartitionLength.QuadPart =
(commonExtension->PartitionLength.QuadPart <<
fdoExtension->SectorShift);

----------------------

The code rounds the number of cylinders to (32*64) for DISK_GEOMETRY, which
results
in a wrong value returned to the caller. The number of sectors becomes
wrong, too (TracksPerCylinder * SectorsPerTrack * Cylinders).

IOCTL_DISK_GET_DRIVE_LAYOUT and IOCTL_DISK_GET_PARTITION_INFO return the
correct media capacity in
PARTITION_INFORMATION.PartitionLength. The difference between
PARTITION_INFORMATION and DISK_GEOMETRY prevents
certain filesystems, including NTFS, from being mounted from
CD/DVD/BD/HDDVD/...

>> // we've defaulted to 32/64 forever. don't want to change this now...

I think now it's a good time to fix it at last, at least for Vista.

Thanks

Mark
Thu Mar 09 08:41:05 CST 2006

cristalink wrote:
> In DDK2000...WDK 5112, CDROM.SYS!CdRomInterpretReadCapacity contains the
> following code:
>

DiskGeometry values are bogus for lots of reasons.
IOCTL_DISK_GET_LENGTH_INFO is more reliable.

> ----------------------------
> //
> // Calculate media capacity in bytes.
> //
> commonExtension->PartitionLength.QuadPart = (LONGLONG)(lastSector + 1);
>
> //
> // we've defaulted to 32/64 forever. don't want to change this now...
> //
>
> fdoExtension->DiskGeometry.TracksPerCylinder = 0x40;
> fdoExtension->DiskGeometry.SectorsPerTrack = 0x20;
>
> //
> // Calculate number of cylinders.
> //
>
> fdoExtension->DiskGeometry.Cylinders.QuadPart = (LONGLONG)((lastSector +
> 1) / (32 * 64));
>
> commonExtension->PartitionLength.QuadPart =
> (commonExtension->PartitionLength.QuadPart <<
> fdoExtension->SectorShift);
>
> ----------------------
>
> The code rounds the number of cylinders to (32*64) for DISK_GEOMETRY, which
> results
> in a wrong value returned to the caller. The number of sectors becomes
> wrong, too (TracksPerCylinder * SectorsPerTrack * Cylinders).
>
> IOCTL_DISK_GET_DRIVE_LAYOUT and IOCTL_DISK_GET_PARTITION_INFO return the
> correct media capacity in
> PARTITION_INFORMATION.PartitionLength. The difference between
> PARTITION_INFORMATION and DISK_GEOMETRY prevents
> certain filesystems, including NTFS, from being mounted from
> CD/DVD/BD/HDDVD/...
>
>
>>>// we've defaulted to 32/64 forever. don't want to change this now...
>
>
> I think now it's a good time to fix it at last, at least for Vista.
>
> Thanks
>
>

cristalink
Thu Mar 09 11:19:14 CST 2006

"Mark Roddy" <markr@hollistech.com> wrote in message
news:uorNYe4QGHA.4920@tk2msftngp13.phx.gbl...
> cristalink wrote:
>> In DDK2000...WDK 5112, CDROM.SYS!CdRomInterpretReadCapacity contains the
>> following code:
>>
>
> DiskGeometry values are bogus for lots of reasons.

Such as...? Yeah, I see... They are to screw things up.

> IOCTL_DISK_GET_LENGTH_INFO is more reliable.

Please tell this to Microsoft. It's their NTFS chokes on their
DISK_GEOMETRY.

--






"Mark Roddy" <markr@hollistech.com> wrote in message
news:uorNYe4QGHA.4920@tk2msftngp13.phx.gbl...
> cristalink wrote:
>> In DDK2000...WDK 5112, CDROM.SYS!CdRomInterpretReadCapacity contains the
>> following code:
>>
>
> DiskGeometry values are bogus for lots of reasons.
> IOCTL_DISK_GET_LENGTH_INFO is more reliable.
>
>> ----------------------------
>> //
>> // Calculate media capacity in bytes.
>> //
>> commonExtension->PartitionLength.QuadPart = (LONGLONG)(lastSector +
>> 1);
>>
>> //
>> // we've defaulted to 32/64 forever. don't want to change this
>> now...
>> //
>>
>> fdoExtension->DiskGeometry.TracksPerCylinder = 0x40;
>> fdoExtension->DiskGeometry.SectorsPerTrack = 0x20;
>>
>> //
>> // Calculate number of cylinders.
>> //
>>
>> fdoExtension->DiskGeometry.Cylinders.QuadPart =
>> (LONGLONG)((lastSector +
>> 1) / (32 * 64));
>>
>> commonExtension->PartitionLength.QuadPart =
>> (commonExtension->PartitionLength.QuadPart <<
>> fdoExtension->SectorShift);
>>
>> ----------------------
>>
>> The code rounds the number of cylinders to (32*64) for DISK_GEOMETRY,
>> which results
>> in a wrong value returned to the caller. The number of sectors becomes
>> wrong, too (TracksPerCylinder * SectorsPerTrack * Cylinders).
>>
>> IOCTL_DISK_GET_DRIVE_LAYOUT and IOCTL_DISK_GET_PARTITION_INFO return the
>> correct media capacity in
>> PARTITION_INFORMATION.PartitionLength. The difference between
>> PARTITION_INFORMATION and DISK_GEOMETRY prevents
>> certain filesystems, including NTFS, from being mounted from
>> CD/DVD/BD/HDDVD/...
>>
>>
>>>>// we've defaulted to 32/64 forever. don't want to change this now...
>>
>>
>> I think now it's a good time to fix it at last, at least for Vista.
>>
>> Thanks
>>

Eliyas
Thu Mar 09 15:02:34 CST 2006

This is what our storage guys had to say:

"Disk "geometry" is out-of-date. Just read the capacity of the media to
determine how many sectors actually exist. The OS cannot change at this
point, because we have no ideas who is impacted. The OS _can_ provide a new
alternative API that returns correct information, which is why I say to just
read the capacity. Tracks/Cylinders don't mean anything anymore on the
majority of today's HDDs. Avoid it like the plague."

"One could imagine this is even less meaningful on a device that has spiral
track(s) :)"


--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx

cristalink
Thu Mar 09 15:22:54 CST 2006

Hi Eliyas,

Could you pass that reply on to your NTFS team?

NTFS and/or fs_rec still relies on the disk geometry for some reason.

For example, I have a piece of MMC media (say, Blu ray or Iomega REV) that
is formatted with NTFS on a third party system, say Unix. Formatted
properly, i.e. all the sectors on the media are taken into account.

Now I feed this media to Windows. The latter doesn't recognize the disk
because Windows NTFS relies on the geometry which is wrong.

Thank you.



"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
news:%230XQLz7QGHA.1576@tk2msftngp13.phx.gbl...
> This is what our storage guys had to say:
>
> "Disk "geometry" is out-of-date. Just read the capacity of the media to
> determine how many sectors actually exist. The OS cannot change at this
> point, because we have no ideas who is impacted. The OS _can_ provide a
> new alternative API that returns correct information, which is why I say
> to just read the capacity. Tracks/Cylinders don't mean anything anymore on
> the majority of today's HDDs. Avoid it like the plague."
>
> "One could imagine this is even less meaningful on a device that has
> spiral track(s) :)"
>
>
> --
> -Eliyas
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx
>
>

Mark
Thu Mar 09 18:42:54 CST 2006

On Fri, 10 Mar 2006 10:22:54 +1300, "cristalink"
<cristalink@nospam.nospam> wrote:

>Hi Eliyas,
>
>Could you pass that reply on to your NTFS team?
>
>NTFS and/or fs_rec still relies on the disk geometry for some reason.
>
>For example, I have a piece of MMC media (say, Blu ray or Iomega REV) that
>is formatted with NTFS on a third party system, say Unix. Formatted
>properly, i.e. all the sectors on the media are taken into account.
>
>Now I feed this media to Windows. The latter doesn't recognize the disk
>because Windows NTFS relies on the geometry which is wrong.
>


As far as I can tell the only reliance that NTFS makes on DiskGeometry
information is the BytesPerSector field. If that value is bogus NTFS
will indeed give up on the device. NTFS ignores the rest of the
nonsense in the DiskGeometery information returned from the call to
IOCTL_DISK_GET_DRIVE_GEOMETRY. The device length information is
obtained from a call to IOCTL_DISK_GET_LENGTH_INFO.


>Thank you.
>
>
>
>"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
>news:%230XQLz7QGHA.1576@tk2msftngp13.phx.gbl...
>> This is what our storage guys had to say:
>>
>> "Disk "geometry" is out-of-date. Just read the capacity of the media to
>> determine how many sectors actually exist. The OS cannot change at this
>> point, because we have no ideas who is impacted. The OS _can_ provide a
>> new alternative API that returns correct information, which is why I say
>> to just read the capacity. Tracks/Cylinders don't mean anything anymore on
>> the majority of today's HDDs. Avoid it like the plague."
>>
>> "One could imagine this is even less meaningful on a device that has
>> spiral track(s) :)"
>>
>>
>> --
>> -Eliyas
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx
>>
>>
>


=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

cristalink
Thu Mar 09 19:25:10 CST 2006

Do you have access to the NTFS sources?

I have a test driver that exposes a MMC device as a hard disk, and I can
format the media with NTFS by formatting the virtual HDD.

If the virtual HDD reports the same number of sectors as on the actial
media, Windows does not recognize the media when it's accessed by the CD
drive letter.

If the virtual HDD reports the rounder number of sectors as per the bogus CD
geometry, the media is recognized by Windows as NTFS-formatted when accessed
as CD.

It can be fs_rec.sys that relies on the geometry.



"Mark Roddy" <markr@hollistech.com> wrote in message
news:nii1121s4de1l8npeiq11h3mgbf350s4dl@4ax.com...
> On Fri, 10 Mar 2006 10:22:54 +1300, "cristalink"
> <cristalink@nospam.nospam> wrote:
>
>
> As far as I can tell the only reliance that NTFS makes on DiskGeometry
> information is the BytesPerSector field. If that value is bogus NTFS
> will indeed give up on the device. NTFS ignores the rest of the
> nonsense in the DiskGeometery information returned from the call to
> IOCTL_DISK_GET_DRIVE_GEOMETRY. The device length information is
> obtained from a call to IOCTL_DISK_GET_LENGTH_INFO.
>

Jeff
Fri Mar 10 10:24:29 CST 2006

NTFS is not supported by Microsoft on optical media (or flash). There is no
plan to change that. I understand that you can do experiments that show
under certain circumstances you are able to read an NTFS filesystem, but
that doesn't alter the fact that it's not supported.


"cristalink" <cristalink@nospam.nospam> wrote in message
news:uUpk6F%23QGHA.2436@TK2MSFTNGP11.phx.gbl...
> Do you have access to the NTFS sources?
>
> I have a test driver that exposes a MMC device as a hard disk, and I can
> format the media with NTFS by formatting the virtual HDD.
>
> If the virtual HDD reports the same number of sectors as on the actial
> media, Windows does not recognize the media when it's accessed by the CD
> drive letter.
>
> If the virtual HDD reports the rounder number of sectors as per the bogus
> CD geometry, the media is recognized by Windows as NTFS-formatted when
> accessed as CD.
>
> It can be fs_rec.sys that relies on the geometry.
>
>
>
> "Mark Roddy" <markr@hollistech.com> wrote in message
> news:nii1121s4de1l8npeiq11h3mgbf350s4dl@4ax.com...
>> On Fri, 10 Mar 2006 10:22:54 +1300, "cristalink"
>> <cristalink@nospam.nospam> wrote:
>>
>>
>> As far as I can tell the only reliance that NTFS makes on DiskGeometry
>> information is the BytesPerSector field. If that value is bogus NTFS
>> will indeed give up on the device. NTFS ignores the rest of the
>> nonsense in the DiskGeometery information returned from the call to
>> IOCTL_DISK_GET_DRIVE_GEOMETRY. The device length information is
>> obtained from a call to IOCTL_DISK_GET_LENGTH_INFO.
>>
>
>

Pavel
Sat Mar 11 15:39:37 CST 2006

"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message news:eLXPZ8FRGHA.1728@TK2MSFTNGP11.phx.gbl...
> NTFS is not supported by Microsoft on optical media (or flash). There is no plan to change that

Even for embedded OS?

--PA

cristalink
Sat Mar 11 19:31:47 CST 2006

So it's a "feature", not a bug. Sorry then. Thank you for the reply.




"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:eLXPZ8FRGHA.1728@TK2MSFTNGP11.phx.gbl...
> NTFS is not supported by Microsoft on optical media (or flash). There is
> no plan to change that. I understand that you can do experiments that show
> under certain circumstances you are able to read an NTFS filesystem, but
> that doesn't alter the fact that it's not supported.
>
>
> "cristalink" <cristalink@nospam.nospam> wrote in message
> news:uUpk6F%23QGHA.2436@TK2MSFTNGP11.phx.gbl...
>> Do you have access to the NTFS sources?
>>
>> I have a test driver that exposes a MMC device as a hard disk, and I can
>> format the media with NTFS by formatting the virtual HDD.
>>
>> If the virtual HDD reports the same number of sectors as on the actial
>> media, Windows does not recognize the media when it's accessed by the CD
>> drive letter.
>>
>> If the virtual HDD reports the rounder number of sectors as per the bogus
>> CD geometry, the media is recognized by Windows as NTFS-formatted when
>> accessed as CD.
>>
>> It can be fs_rec.sys that relies on the geometry.
>>
>>
>>
>> "Mark Roddy" <markr@hollistech.com> wrote in message
>> news:nii1121s4de1l8npeiq11h3mgbf350s4dl@4ax.com...
>>> On Fri, 10 Mar 2006 10:22:54 +1300, "cristalink"
>>> <cristalink@nospam.nospam> wrote:
>>>
>>>
>>> As far as I can tell the only reliance that NTFS makes on DiskGeometry
>>> information is the BytesPerSector field. If that value is bogus NTFS
>>> will indeed give up on the device. NTFS ignores the rest of the
>>> nonsense in the DiskGeometery information returned from the call to
>>> IOCTL_DISK_GET_DRIVE_GEOMETRY. The device length information is
>>> obtained from a call to IOCTL_DISK_GET_LENGTH_INFO.
>>>
>>
>>
>
>