Jump to content

drive ejected even though locked for exclusive use


Ch3vr0n

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Ch3vr0n
Link to comment
Share on other sites

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 by Ch3vr0n
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Ch3vr0n
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.