Ultima Posted December 14, 2009 Posted December 14, 2009 I know, hard drive storage is cheap, but... with processors being as powerful as they're getting, why not support burning images that are stored inside .zip files or such? Where I work, Imgburn is used primarily to image and burn OS recovery media. Some of the disk images that we store can be compressed quite well by simple .zip or .7z. However, if we compress them, we would have to expand them every time we wanted to burn one, so why can't Imgburn on-the-fly burn a compressed image?
ianymaty Posted December 15, 2009 Posted December 15, 2009 No offence! If an archive is damaged? How about that?
Ultima Posted December 16, 2009 Author Posted December 16, 2009 On 12/15/2009 at 5:45 PM, ianymaty said: If an archive is damaged? How about that? I suspect the same thing would happen as if the image file itself was damaged. Also, it's a smaller file if it's compressed, meaning that it occupies less sectors of disk space, which in turn means the chances of a particular sector flaking out and ruining one of my images is lessened by ((uncompressed size of image)-(size of compressed image))/(uncompressed size of image)%. This means that by compressing my disk images, I would be increasing reliability! Seriously though, I'd expect both a damaged archive to not work. I would also expect a damaged image file to not work either, so it's a non-issue.
ianymaty Posted December 16, 2009 Posted December 16, 2009 See?! People sometimes like to complicate things were they shouldn't. A damaged image in a damaged archive... Forget about it...
ssjkakaroto Posted December 26, 2009 Posted December 26, 2009 You're the one that mentioned damage ianymaty, thus complicating the request, not the OP In fact, he de-complicated things when he said he didn't care. But, IIRC, this has been requested before and it seems LUK isn't implementing this one anytime soon...
ianymaty Posted December 28, 2009 Posted December 28, 2009 Yes, I complicated things more, just to show that the idea is not quite so good. Good image + good compression + good (realtime) decompression + good burn & verify OK, (not calculating the media) = the IDEAL RESULT what is wished, but if just one of the variables fail, the result will be coaster. Now, try to find the culprit for the bad result. It's just time and nerves consuming... Let's keep it simple...
Ultima Posted December 29, 2009 Author Posted December 29, 2009 Assume that media is cheap and plentiful. Nowadays, it is. A simple dialog (toggle-able in preferences) could suffice as a warning. "ImgBurn does not recommend real time decompression of compressed images. Would you like to proceed anyway?" It's simple and to the point. Plus, if you don't want to burn compressed images, nobody would be forcing you to. I merely added it as a suggestion as it is something that I would honestly like to see in ImgBurn.
ianymaty Posted December 30, 2009 Posted December 30, 2009 ImgBurn is a burning tool, not decompressor. For decompressing it will have to call another program to do the job by a plugin or something. I don't think LUK will gonna do that. We just arguing in comments but LUK said numerous times that ImgBurn is a burning tool and not gonna change the purpose of the tool to suit everybody's like. He just want, like most of us, a simple and reliable burning tool not a 100 function "Swiss Knife" tool.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now