drive ejected even though locked for exclusive use

[Ch3vr0n]

I stumbled upon this issue while doing the erasing for my other topic. So while the BH16 was erasing a disc, i fired up another instance to burn an iso to disc in my bh10. During load the bh16 obviously wasn't accessible during the start of the program. Now here's the catch. I loaded the ISO, and accidentaly forgot to swap the drive at the bottom from the bh16 to the bh10 and pressed "go". The 2nd imgburn instance started burning and a few seconds later, the "erasing imgburn" errored out and ejected the tray which obviously aborted the burn on the 2nd instance.

 

Is this normal behavior? Shouldn't the "lock for exclusive access" (which i have all 4 boxes marked, defaults) have prevented this from happening? Or is it since it's also imgburn, that this is overridden?

[LIGHTNING UK!]

If the drive is locked for exclusive usage, the program won't be able to do anything with it (the OS handles it and rejects attempts to use it) and it won't get added to the source/destination box.

 

As such, there's no way for you not to have changed it from the bh16 to bh10 as it wouldn't be in the box to begin with.

[Ch3vr0n]

i can reproduce it.

 

1. Start imgburn

2. start to erase a disc (full disc)

3. launch 2nd instance

4. select Burn image to disc

5. "Busy" drive is listed in "destination" even though the log states "access denied" and bh16 is selected as default drive

6. select image > leave destination to bh16

7. press burn

8. error message, click continue

9. instance 2 begins burn

10. instance 1 errors and ejects tray.

Edited August 5, 2016 by Ch3vr0n

[LIGHTNING UK!]

Can you post the log please.. always post the log

[Ch3vr0n]

seems like it's actually instance 2 that ejects it Anyway attached is the log. I pressed burn on instance 2 when instance 1 was 1% into zeroing sectors. Then closed both instances in the order of instance 1 first, 2nd instance last. though it seems instance are saved with first closed at the bottom. Attached is the log.

 

In case it matters. Running Win 10 Pro x64 build 1607

 

G:\ bh16

H:\ bh10

I:\ dvd ram

ImgBurn.log

Edited August 6, 2016 by Ch3vr0n

[LIGHTNING UK!]

Right, the problem here is that you've changed the I/o interface. It only works how I've described it when using the default spti one.

 

I don't know why it's not locking it properly when using ElbyCDIO, the locking mechanism is handled by the driver itself rather than ImgBurn. Maybe something has changed?

[Ch3vr0n]

Dunno, new system. My old one was running win 7. Can't say I deliberately reproduced this issue on win 7. Stumbled on this by accident. Using Microsoft's crap spti just isn't an option. Fails to properly Identify disc MID's. Posted a topic about that a long time ago. Was using elbycdio on 7 too and the same drives. So the only change is the os. Maybe it's something you can look into for the next version of ImgBurn. Just wanted to report it, it's not a big issue. Just need to keep an extra eye open that the correct drives are select per instance.

[LIGHTNING UK!]

If you posted a topic about it long ago, is it really still an issue for you? I've only ever used spti and never had a problem with it.

 

I have roughly the same issue as you if I used elbycdio on Windows 7. The drive is still accessible in the 2nd instance of ImgBurn, even though the elbycdio driver claims it has locked the drive successfully.

 

I could try contacting someone to see if elby/ SlySoft/RedFox can explain what's going on. My details on the interface date back *many* years now.

[Ch3vr0n]

Back then it failed to properly find the MID for my verbatims. You then advised me to swap to the elby engine and the drives properly found it. Ever since then i've used elbcdio, i have the full elby/redfox product suite anyway. I don't know how good your connections are but mine are very active (since i'm doing the NL translating for them), i've got a couple direct lines to both elby and redfox So who's going to contact them?

[LIGHTNING UK!]

I had a go at burning a disc with clonebd to see what it did and it doesn't appear to lock the drive at all when it burns. Other apps can still use the drive (via both elbycdio and via spti) when it's burning.

 

I was hoping to find it made use of some superior locking method, but it appears it doesn't.

 

I've emailed someone and asked if they can assist.

[Ch3vr0n]

Let me know if you need me to do any testing. Feel free to email to if needed.

[LIGHTNING UK!]

Ok so it turns out that ElbyCDIO's 'Exclusive Access' function only locks out the window file system, it doesn't lock out anything else... including other instances of ImgBurn using ElbyCDIO or indeed, SPTI.

 

So the only way to really lock it out is to use SPTI as mentioned earlier.

[Ch3vr0n]

Are there plans to update it so it actually locks it out completely?

 

** Edit ** or a workaround for this 'issue' in a future version of ImgBurn perhaps in case elby has no plans to do that.

Edited August 13, 2016 by Ch3vr0n

[LIGHTNING UK!]

It's 'by design', so I doubt it'll change.

 

As for a workaround, using the default I/O method is it

[Ch3vr0n]

Guess I could think about it. Barring the 'drive locking' spti, are there significant benefits or improvements that either one has over the other? I've used elby for as long as I can remember after being told once to swap 'engine' because spti couldn't properly identify disc mid.

[LIGHTNING UK!]

SPTI is the only one I've ever really used and the only one gets updates within my program code.

 

Because SPTI is all done via Microsoft's API, there are other bits of code that can tie in with the core I/O stuff... like where it can show a device's 'Family Tree' and the speed of a USB connection.