Bug in InCD 4.0.1.21 or Info Toll 2.0.0.0

[kaikow]

Installed Nero 6.0.0.9, InCD 4.0.1.21 on Win 2000 SP 4.

Tried using Nero Info Tool 2.0.0.0 with CD-RW media in CD-RW drive.

Error message was:

Drive E: is locked by InCD server
(Code 5020).

On the same system, I have a separate Win 98 and another separate Win 2000 partition. Both have Nero 5.5.10.42 and InCD 3.5.24.0. Using Nero Info Tool 1.0.3.3, there's no problem.

CD-RW is ATAPI PLextor PX-W4824TA, Master on Primary IDE Controller
CD-ROM is SCI PLextor PX-32TSi

All hard drives are SCSI.
Tape drive is SCSI.
ZIP drive is Master on SEcondary IDE Controller.
No slave drives.

[dodecahedron]

you can try to isoloate the problem to InCD 4.0.1.21 or InfoTool 2, by running InfoTool 2 on one of the other systems that have Nero 5.5 and InCD 3.5.

[dodecahedron]

drivers of Zip drives are know to be problematic and conflicting with packet-writing software such as InCD.

i suggest you give serious consideration to whether you really need the Zip drive, i recommend you remove it.

[kaikow]

Your wish, at least this one, is my command!

Ran Info Tool 2 with Win 2000 on G drive, which has Nero 5.5.10.42 and InCD 3.5.24.0.

Problem did not occur, which further points the finger to the combination of Nero 6.0.0.9 and InCD 4.0.1.21.

you can try to isoloate the problem to InCD 4.0.1.21 or InfoTool 2, by running InfoTool 2 on one of the other systems that have Nero 5.5 and InCD 3.5.

[kaikow]

ZIP drive is on different IDE Controller, so is unlikely to cause a problem.

I've not seen ANY problems caused by ZIP drive.

drivers of Zip drives are know to be problematic and conflicting with packet-writing software such as InCD.

i suggest you give serious consideration to whether you really need the Zip drive, i recommend you remove it.

[dburg]

Is the CD-RW media InCD-formatted?

[kaikow]

Is the CD-RW media InCD-formatted?

I think so.

How can I tell for sure?

[dhc014]

Is the CD-RW media InCD-formatted?

I think so.

How can I tell for sure?

Format it.

[kaikow]

I'm not going to change extant recording on media just for a test.

I asked how to tell what is the current format.

Is the CD-RW media InCD-formatted?

I think so.

How can I tell for sure?

Format it.

[kaikow]

Problem occurs using media formatted with other than InCD 4.0.1.21 using InfoTool 2 on a system with InCD 4.0.1.21 installed.

Yes, problem occurs with media formatted using InCD 3.5.24.0.

Problem does NOT occur using InfoTool 2 on a system with InCD 3.5.24.0 installed, even if the media had been formatted with InCD 4.0.1.21.

[dburg]

Is the CD-RW media InCD-formatted?

I think so.

How can I tell for sure?

Go to the properties page of your drive. On the first tab will be given the currently mounted filesystem. For InCD, it is "INCDFS".

In case of a InCD media inserted, it is normal that Nero InfoTool cannot test the media. The reason is that to protect from intrusive scsi commands from one software to another Ahead implement a cooperative locking mechanism. That is, Nero will not take InCD's media without asking for it first, as well as InCD will not grab a media on a device Nero is working on, etc... Nero InfoTool participate to this cooperative locking mechanism.

I am not personnaly the author of Nero InfoTool so I am unsure of the details, but I think it does not yet include the capacity to issue to InCD a request to get the media. But I guess this is under development.

Only new software of Ahead include this new cooperative locking technology, thus you do not see it in activity with InCD 3.x

[kaikow]

1. If media is recorded using an ISO 9660 or ISO/EC 13346 conforming format, not to mention other well knon formats, NO software has any business restricting access to the media.

2. Appears that Nero's Info Tool is poorly conceived. The whole idea of a tool is to let you know what's on the media to analyze problems.

Is the CD-RW media InCD-formatted?

I think so.

How can I tell for sure?

Go to the properties page of your drive. On the first tab will be given the currently mounted filesystem. For InCD, it is "INCDFS".

In case of a InCD media inserted, it is normal that Nero InfoTool cannot test the media. The reason is that to protect from intrusive scsi commands from one software to another Ahead implement a cooperative locking mechanism. That is, Nero will not take InCD's media without asking for it first, as well as InCD will not grab a media on a device Nero is working on, etc... Nero InfoTool participate to this cooperative locking mechanism.

I am not personnaly the author of Nero InfoTool so I am unsure of the details, but I think it does not yet include the capacity to issue to InCD a request to get the media. But I guess this is under development.

Only new software of Ahead include this new cooperative locking technology, thus you do not see it in activity with InCD 3.x

[dburg]

1. If media is recorded using an ISO 9660 or ISO/EC 13346 conforming format, not to mention other well knon formats, NO software has any business restricting access to the media.

Oups, I should have been deeper in the details to clarify why we are doing this.

Yes, ISO and alike do not have such restriction, as well as udf reader from Microsoft won't have this restriction, and in fact, any read-only filesystem.

The purpose of protecting against intrusive commands from other software is that when you write to a media, the write is buffered and done later. But, as a write command might fail, the error will need to be deferred. This report of deferred error is done once the error occured the next time a command is received. This next command could be as well a read as a write command. The problematic case is when several host speaks at the same time to the same logical unit, then a host can potentially receive the deferred error from a command issued by another host. Argh, 2 problems:

- the host who receive the error believe his command failed, but in fact it's a command from another host which failed

- the host which error was "stolen" does not know about the problem, and will continue to run normally. This mean that if a write command failed, it will not be re-attempted or re-allocated to a safe block. Data loss!

[kaikow]

So what does that have to do with my original posting in this thread?

Nero Info Tool is supposed to return info about drives and media in the drives.

Returning such info need not be affected by other apps accessing such drives.

The use of the drive could be momentarily frozen while the info is obtained, however, InCD 4.0.1.21 appears to be (mis)designed to get in the way of other software.

1. If media is recorded using an ISO 9660 or ISO/EC 13346 conforming format, not to mention other well knon formats, NO software has any business restricting access to the media.

Oups, I should have been deeper in the details to clarify why we are doing this.

Yes, ISO and alike do not have such restriction, as well as udf reader from Microsoft won't have this restriction, and in fact, any read-only filesystem.

The purpose of protecting against intrusive commands from other software is that when you write to a media, the write is buffered and done later. But, as a write command might fail, the error will need to be deferred. This report of deferred error is done once the error occured the next time a command is received. This next command could be as well a read as a write command. The problematic case is when several host speaks at the same time to the same logical unit, then a host can potentially receive the deferred error from a command issued by another host. Argh, 2 problems:

- the host who receive the error believe his command failed, but in fact it's a command from another host which failed

- the host which error was "stolen" does not know about the problem, and will continue to run normally. This mean that if a write command failed, it will not be re-attempted or re-allocated to a safe block. Data loss!

[kaikow]

Looking at the properties page does not tell me what was used to write the files. At best, it tells me what system CLAIMS to have recorded certain volume or file descriptors.

Nero, InCD, Roxio, etc, ALL have to work no matter what software did the recording, provided the software followed one of the accepted standards, i.e., ISO 9660 or ISO/IEC 13346 or ECMA-167, or allegedly standard conforming adaptations of those standards, e.g., UDF.

Is the CD-RW media InCD-formatted?

I think so.

How can I tell for sure?

Go to the properties page of your drive. On the first tab will be given the currently mounted filesystem. For InCD, it is "INCDFS".

In case of a InCD media inserted, it is normal that Nero InfoTool cannot test the media. The reason is that to protect from intrusive scsi commands from one software to another Ahead implement a cooperative locking mechanism. That is, Nero will not take InCD's media without asking for it first, as well as InCD will not grab a media on a device Nero is working on, etc... Nero InfoTool participate to this cooperative locking mechanism.

I am not personnaly the author of Nero InfoTool so I am unsure of the details, but I think it does not yet include the capacity to issue to InCD a request to get the media. But I guess this is under development.

Only new software of Ahead include this new cooperative locking technology, thus you do not see it in activity with InCD 3.x

[dburg]

So what does that have to do with my original posting in this thread?

It explains why you see:

"Error message was:

Drive E: is locked by InCD server
(Code 5020). "

As you reported in your original posting.

Nero Info Tool is supposed to return info about drives and media in the drives.

Absolutely.

Returning such info need not be affected by other apps accessing such drives.

... as well as it needs to not disturb other apps activity.

The use of the drive could be momentarily frozen while the info is obtained, however, InCD 4.0.1.21 appears to be (mis)designed to get in the way of other software.

Sorry, I cannot let you tell that. InCD 4 supports the Microsoft's IOCTL lock volume for any application wanting to do direct low-level access by-passing the filesystem (this is documented within the MSDN Library). Which is what Nero InfoTool do (direct access to the hardware). So I do not think InCD 4 is misdesigned, on the contrary, it supports existing Microsoft's IOCTL and add to this an Ahead-designed activity signal that both InCD and Nero InfoTool (and other Ahead products) uses to signal each other they action on devices.

Of course Nero InfoTool need to be improved to momentarily "froze" the activity on the device as you described, thus be able to retrieve disc information also for devices currently in use by InCD (or other Ahead app when it is possible to "froze" the activity, which might not be always possible, eg. not possible when Nero burn a compilation).