Hi all,

I researched this topic for quite some time now but didn't find a satisfying solution. I stumbled across the NeroSDK and saw that they actually CAN provide both drive letter and SCSI ha/target/lun information for a single drive.
If anyone can provide information on how that is accomplished without using the NeroSDK, I'd be VERY greatful.

Thanks,
Alex

It is tricky, and unreliable but here was my code. Doesn't work on 9X because of the DeviceIO call and doesn't work for USB/Firewire devices. I wish I could remember where I got a good portion of this code, but don't remember. You can browse the newsgroups and find pretty close to this...
This is one of the main reasons I switched over to the nero SDK.

// Create the device name
strcpy((char*)deviceName, "\\\\.\\d:");

// Open the device.
deviceHandle = CreateFile((char*)deviceName,
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL
);

// Error getting the device handle for the drive
if (INVALID_HANDLE_VALUE == deviceHandle) {
errorCode = GetLastError();
strMsg = "Burner: CreateFile failed.";
return FALSE;
}

// Clear out the buffer
ZeroMemory(&dataBuffer[0], sizeof(dataBuffer));

// Get the device address information.
if (!DeviceIoControl(deviceHandle,
IOCTL_SCSI_GET_ADDRESS,
NULL,
0,
dataBuffer,
sizeof(dataBuffer),
&bytesReturned,
FALSE)) {

// Failed. Log error messages.
errorCode = GetLastError();

strMsg = "Burner: Device IOCTL failed.";
gSystemMgr->LogEvent ( errorCode, EVT_ERROR, strMsg );

// Close open handle and return error to caller.
CloseHandle(deviceHandle);

return FALSE;
}

// Local address value
myAddress = (PSCSI_ADDRESS) dataBuffer;

// If return successful, but size does not match
if (bytesReturned != sizeof(SCSI_ADDRESS)) {
strMsg = "Burner: Device IOCTL returned incorrect size of SCSI_ADDRESS.";
gSystemMgr->LogEvent ( 0, EVT_ERROR, strMsg );
// Close device handle.
CloseHandle(deviceHandle);
return FALSE;
}

// Close device handle.
CloseHandle(deviceHandle);

// Loop through the CDWriter list to find a match
i=0;
while(i < devCount && !found) {

// If the current device matches the specified drive's id
if ((devList[i]->GetId() == (UBYTE) myAddress->TargetId) &&
(devList[i]->GetAdapter() == (UBYTE) myAddress->PortNumber) &&
(devList[i]->GetLogUnitNum() == (UBYTE) myAddress->Lun)) {

found = TRUE;
// use this drive to burn files for this class instance
} // end else (! 98 or me)

i++;
}

Thanks for your reply,

Yeah, I already tried that. But windows SPTI seems to use different adapter IDs than ASPI for IDE drives. So that doesn't really work for IDE drives (as far as I researched that...)

Cheers,
Alex

I had no problems with IDE connected CD or DVD drives with that code...

Guess it depends on why you want to know those values. I was using them to compare against values from an ASPI driver to verify whether or not a CD/DVD was writable.

I want to know which ha/t/l to access when a drive letter is specified. the DeviceIoControl() does actually succeed in finding a a/t/l for my IDE DVD drive. Unfortunately it's not the same hostID that ASPI finds. So that is no real option. What I want to know is if there is a stable and reliable way of getting a a/t/l for a specific drive letter. How did ahead's people implement that in their NeroSDK? Anyone has info on that?

Cheers,
Alex

Okay, I researched the local problems some more. I consider my findings a bit strange actually. For testing I wrote a application that checks all adapters for devices. I am using Nero's ASPI implementation for testing here. I have a NEC DVD burner attached to my ATA bus. Windows correctly detects the ATA bus as a host adapter and lists the DVD drive as attached to it (as 0/0/0). ASPI however doesn't. It doesn't list any devices for that ATA host adapter. ASPI lists the DVD burner as attached to a unnamed adapter (as 2/0/0).
Any idea why this happens? Or how to get around it? This really drives me crazy! After all it can't be that hard to get ha/tar/lun for a drive letter, can it?

Cheers,
Alex

Everything I have seen about drive letter mapping really depends on the ASPI dll used. I had talked with Don Matthews, who writes the Nexitech driver, a while back. I asked him how he mapped the ha/tar/lun and used his algorithm to verify a drive. It gets trickier with USB and Firewaire devices. How do they map in? He assigned the HA to those devices as he discovered them. The Nexitech and Nero ASPI drivers are the only two drivers that I have seen that map the drive letter with the device. In short, there is no completely reliable way to map the devices because they really do not have SCSI addresses. Nexitech seemed to follow the Windows convention for ha/tar/lun, but I chose the Nero ASPI because it was faster and more reliable.

So you say there is no reliable way to resolve driver letters to SCSI to ha/tar/lun? Hm. Not good.

You can use the Nero SDK and their mapping of drive letters to ha/tar/lun...

Hm. Unfortunately NeroSDK is no option. Also it's not guaranteed that ahead's ASPI dll will be used on the end user's system...