Delete Image Bug in 2.1.0.0 on Failed Burn

[coby]

While attempting to write to a DVD+RW disc, several errors occurred during the burn. This is probably due to a dirty or defective disc. At the end of the burn, an error when 'Synchronising Cache' prompted me to retry or cancel. I chose to cancel, figuring I could requeue the image and try with a different disc. However, the image file was deleted even though the burn failed.

 

This was the first image in a queue of 4. Version 2.1.0.0 This particular image was not built with ImgBurn.

 

Here is the log. Prior to burning the image, I built two other images in ImgBurn, so please disregard that at the top of the log.

ImgBurn_failed.log

[dontasciime]

did you not choose delete image

[coby]

did you not choose delete image [?]

 

Yes, I chose to Delete Image. Which is what I desire should the burn succeed. However, if the burn fails, I would not want it to delete the image.

 

Maybe IB always deletes regardless of the outcome, but it seems logical to me to not delete if there is a failure. I don't have a lot of burn failures, so I couldn't say, offhand, if IB always deletes.

[polopony]

I never choose delete image for that reason (failed burn) although its been years since I made a coaster .When I'm happy that all has burned fine then I go back to my HD (D ) and delete from there ,its easy enough and you can delete 10 iso's in less than a minute

[LIGHTNING UK!]

It's doesn't delete it if the burn fails.

 

....but, a failure on the sync cache / finalise disc bits is not considered a burn failure.

 

Hence why it says operation completed successfully in the log.

 

That's the bit I need to fix, not the delete bit so to speak.

[coby]

It's doesn't delete it if the burn fails.

 

....but, a failure on the sync cache / finalise disc bits is not considered a burn failure.

 

Hence why it says operation completed successfully in the log.

 

That's the bit I need to fix, not the delete bit so to speak.

 

Thank you for the clarification. I'll consider this a caveat for now.

 

BTW, I never check the 'Delete Image' button unless it's an image I can recreate, so I was more of an annoyance that the process seemed to fail but deleted the image. Most of my 'test' burns use 'Delete Image' since I'm always riding on the edge of a full HD. (Which is silly, since its 500 GB )

 

I just wanted to notify the appropriate parties should there be something that could be looked at, improved, or at least documented here in the forums.

 

Cheers on the excellent proggie!

[Kenadjian]

Good call blain.

[Dolt]

It's doesn't delete it if the burn fails.

 

....but, a failure on the sync cache / finalise disc bits is not considered a burn failure.

 

Hence why it says operation completed successfully in the log.

 

That's the bit I need to fix, not the delete bit so to speak.

 

Thank you for the clarification. I'll consider this a caveat for now.

 

BTW, I never check the 'Delete Image' button unless it's an image I can recreate, so I was more of an annoyance that the process seemed to fail but deleted the image. Most of my 'test' burns use 'Delete Image' since I'm always riding on the edge of a full HD. (Which is silly, since its 500 GB )

 

I just wanted to notify the appropriate parties should there be something that could be looked at, improved, or at least documented here in the forums.

 

Cheers on the excellent proggie!

 

It fails to properly check the status of all burns associate with an image before deleting that image when burning multiple copies as well !!!

 

 

I've had it delete the image when I'm doing multiple copies and there's a failure. Here's EXACTLY what happens!! It will fail on the first image; it will then burn the second copy. If the second copy fails it will not delete it but if the second copy goes OK it WILL delete the image!!! ALWAYS! It does NOT matter what media or drive is involved! It's a logical bug. He only checks the last burn and not all burns before deleting!! It will then ask if you want to re-burn copy 1 you say yes and it queues up to burn it but it has already DELETED it so it FAILS since the image NO LONGER EXISTS since it was deleted by ImgBurn itself. I've had this happen consistently. NEVER use the DELETE IMAGE option when making MULTIPLE COPIES of the same image until he fixes the bug!!!!

 

 

It's particularly annoying since I once do multiple copies of important material.

 

[Dolt]

I never choose delete image for that reason (failed burn) although its been years since I made a coaster .When I'm happy that all has burned fine then I go back to my HD (D ) and delete from there ,its easy enough and you can delete 10 iso's in less than a minute

 

Apparently, since it fails to properly check when making multiple copies I now have to do the same.

 

 

P.S. ? How come CD?s use SAO instead of DAO???

 

[LIGHTNING UK!]

Hmm I hadn't really thought about that particular situation/issue DoIt.

 

All it does before deleting the image is:

 

1. Check the last burn was successful.

2. Check there are no other queued burns that need the image.

 

It doesn't take into account failed burns within a multi copy burn that you may or may not want to retry.

 

The image deletion code is in a different part of the program (and it's run first) to the bit that asks if you want to retry failed burns.

 

So it's not a case of it failing to check properly, just at the time when it does check, so far as the program is concerned, the image is finished with.

 

 

SAO is the naming scheme for CD, for DVD it's DAO. That's just what the MMC specs say. They're the same thing in reality.

[Dolt]

Hmm I hadn't really thought about that particular situation/issue DoIt.

 

All it does before deleting the image is:

 

1. Check the last burn was successful.

2. Check there are no other queued burns that need the image.

 

It doesn't take into account failed burns within a multi copy burn that you may or may not want to retry.

 

The image deletion code is in a different part of the program (and it's run first) to the bit that asks if you want to retry failed burns.

 

So it's not a case of it failing to check properly, just at the time when it does check, so far as the program is concerned, the image is finished with.

 

 

SAO is the naming scheme for CD, for DVD it's DAO. That's just what the MMC specs say. They're the same thing in reality.

 

 

"It doesn't take into account failed burns within a multi copy burn that you may or may not want to retry."

"The image deletion code is in a different part of the program (and it's run first) to the bit that asks if you want to retry failed burns."

 

That's a bad design. You should swap the order of execution.

 

It seems that the problem is you do not redo the first disk so the count is wrong. You have only 1 successful image of 2 then

you simple should NOT advance the count when a verification fails. You should wait until a verification passes and returns a passing value when that condition is set on before advancing to the next image. Instead you apparently do so when the burn finishes. It's bad logic. I do programming myself and bad logic is the cause of most serious bugs. I suppose if you were designing a washing machine you'd start filling it with water once the first quarter is placed in the machine expecting the others will go in as well. What we have here is someone only put two quarters in for a $1 washing machine and you went ahead and said that was "close enough" and ran the wash anyway. It's bad code, period.

 

Actually SAO mean Session At Once. It does NOT finalize a CD like a DAO would. A DAO burn burns one session and then finalizes the CD. A SAO burn burns one sseesion and does NOT finalize the CD so more sessions can be added to the media.

This also means once can actually remove data from the index for the next session and then finalize the CD with the data in the CD but not accessible when loaded into windows. Believe me, I've done dozens of multi-session CDs at this point. You can even do Multi-Session CD-DA CDs where a CD player will only see the first session but a CD-ROM drive will see more tracks that a CD player will not. I've done it. You need either an older version of Win-On-CD to do it.

[LIGHTNING UK!]

Actually, it's done like that because of how the queue works - it was an addon to existing code remember. If I had to start from scratch again, I may well do things differently. At the moment the queue is merely basic automation of program functions.

 

Just before the 'Operation Successfully Completed' box pops up, it does the file deletion... I believe that is the correct order. The queue is processed after that and that's why things happen in the order they do.

 

'Bad Copies' DO count towards the 'Total Copies' the program has burnt of any given image and hence has an effect on 'Remaining Copies' too.

 

I could have just left it without prompting the users if they want to retry failed burns for a given image, but I chose not to. If I hadn't bothered, none of this would be an issue.

 

You have my apologies for the program prematurely deleting your image but you just hit a minor snag that I myself had never run into - I don't get 'failed' burns and I delete my stuff manually. Perhaps you should spend less time playing the typical arrogant programmer (yes, I do it too) and more time fixing all the problems you have with your setup, then this wouldn't be an issue for you either.

 

lol I know how this writing stuff works thanks, I certainly don't need you explaining it to me! When ImgBurn refers to the 'Write Type' of SAO/DAO, it's talking about 1 field within the 'Write Parameters' mode page. I just use those names as they're copied verbatim from the MMC specs. SAO and DAO are one in the same - so far as 'write type' and that mode page are concerned. The multisession field is totally seperate.

[lfcrule1972]

Manual deletions is how I have always run my queues, once all is ok it's quick and easy to do

[Dolt]

Manual deletions is how I have always run my queues, once all is ok it's quick and easy to do

 

He might as well remove the damned option since it's so useless. Nobody can safely use it.

Everyone here says they the besy thing is to NOT use the damned delete option since it's too

dangerous. I thought only Microsoft was dumb enough to leave in defective code that can

cause the user to unwittingly damage their data.

 

[kevdriver]

Dolt, The delete option is there for people to use by choice. I have used it several times with no problems, but like the others I normally just delete the images on my own because of personel preference. This option was implemented in Img because of a user request I imagine and the author thought it would be a good thing to have. Having worked perfect for me, doesn't mean it will work 100% for other peoples issues, there is a lot of variables for one code to cover. Its a poor worker that blames his tools for mishaps. I always test drive my programs before I use them for any serious work I may have. Perhaps the best thing for you to do is delete Img from your computer and find another free program that does the same excellent job that Img does. Good Luck in your search..........

[LIGHTNING UK!]

It's only useless if you get failed burns. If you don't, you'd never know the problem ever existed in the first place. As I said before, I'm sorry and it will be (has been) fixed.

 

You're actually coming across as a complete knob btw and we don't appreciate / tollerate those kinds of people on this forum.