Prev: Emu Browser 2.4 (final free version) Program launcher
Next: A good opportunity to investment
From: Susan Bugher on 23 Feb 2010 15:26
REM wrote:
>> Susan Bugher <sebugher(a)yahoo.com> wrote:

>> *IF* I read the request correctly, the OP wants to burn a copy of the
>> *CONTENTS* of an ISO file => there will (probably) be many files on the
>> CD or DVD that is burned. The OP then wants to verify those files to
>> make sure they are true copies of the files that are CONTAINED WITHIN
>> the single ISO file.
>
>> That's why I recommended DVDSig. :)

> Gotcha!
>
> Another approach is directory/folder checksum?
>
> http://support.microsoft.com/kb/841290
>
> http://www.slavasoft.com/fsum/

Probably. ;) (The problem was not well-defined.)

Susan
--
Posted to alt.comp.freeware
Search alt.comp.freeware (or read it online):
http://www.google.com/advanced_group_search?q=+group:alt.comp.freeware
Pricelessware & ACF: http://www.pricelesswarehome.org
Pricelessware: http://www.pricelessware.org (not maintained)
From: George Orwell on 24 Feb 2010 15:43
Susan Bugher wrote:

> REM wrote:
>>> Susan Bugher <sebugher(a)yahoo.com> wrote:
>
>>> *IF* I read the request correctly, the OP wants to burn a copy of the
>>> *CONTENTS* of an ISO file => there will (probably) be many files on
>>> the CD or DVD that is burned. The OP then wants to verify those files
>>> to make sure they are true copies of the files that are CONTAINED
>>> WITHIN the single ISO file.
>>
>>> That's why I recommended DVDSig. :)
>
>> Gotcha!
>>
>> Another approach is directory/folder checksum?
>>
>> http://support.microsoft.com/kb/841290
>>
>> http://www.slavasoft.com/fsum/
>
> Probably. ;) (The problem was not well-defined.)

The problem was as defined as it could get. Comparing an ISO to a
previously burned disk. Period. The reason you can't find a ready answer
to that problem is Windows' inherent limitations. In general, a file
system that was kludge to begin with, being further corrupted by
Microsoft and its propensity for keeping things proprietary.

There simply *is* no way to directly hash/compare an ISO and a disk under
windows. Modern *nix file systems allow you to access devices directly,
as files. Easy peasy straightforward byte-by-byte comparison. Under
Windows you're forced to essentially generate another ISO from the burned
disk and compare it to the original ISO, a process that can fail
miserably for a number of likely reasons, or you can mount the ISO image
as another drive letter and do a file by file comparison... which really
doesn't tell you much about the actual quality of a burn. And if you're
running XP or earlier you can't even mount the ISO as a drive if memory
serves. That ability first appeared in Vista I believe.

Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore |anonymous system
Per maggiori informazioni |For more info
https://www.mixmaster.it
From: REM on 24 Feb 2010 16:13

> George Orwell <nobody(a)mixmaster.it> wrote:

>The problem was as defined as it could get. Comparing an ISO to a
>previously burned disk. Period. The reason you can't find a ready answer
>to that problem is Windows' inherent limitations. In general, a file
>system that was kludge to begin with, being further corrupted by
>Microsoft and its propensity for keeping things proprietary.

A hash should work in comparing one .iso to another burn of the same
..iso.

> And if you're
>running XP or earlier you can't even mount the ISO as a drive if memory
>serves. That ability first appeared in Vista I believe.

http://majorgeeks.com/Virtual_CD-ROM_Control_Panel_d4402.html

1984 was quite awhile ago. <G>

I've never had any problems burning an .iso (that was not my own
mistake). It just works. :)

From: Nomen Nescio on 25 Feb 2010 15:17
REM wrote:

>> George Orwell <nobody(a)mixmaster.it> wrote:
>
>>The problem was as defined as it could get. Comparing an ISO to a
>>previously burned disk. Period. The reason you can't find a ready answer
>>to that problem is Windows' inherent limitations. In general, a file
>>system that was kludge to begin with, being further corrupted by
>>Microsoft and its propensity for keeping things proprietary.
>
> A hash should work in comparing one .iso to another burn of the same
> .iso.

No, it would likely fail for a number of reasons. The most prominent one
being that *most* burning software appends some number of bytes to the
end of a burned disk. They're block devices after all. ;)

It *might* work if you use the same software you used to burn the disk in
the first place, but that's not a guarantee. That software would have to
somehow "remember" which bytes were added and their values. Probably not
going to happen after the fact. Software that verifies after a burn has
that information available to it at burn time, but not 6 weeks later.

>> And if you're
>>running XP or earlier you can't even mount the ISO as a drive if memory
>>serves. That ability first appeared in Vista I believe.
>
> http://majorgeeks.com/Virtual_CD-ROM_Control_Panel_d4402.html
>
> 1984 was quite awhile ago. <G>

Yes, but that's not Windows. It's part of the "deer in the headlights"
aspect of the problem. You're searching for a way to end run a Windows
file system limitation, and not really addressing the root problem itself
in any acceptable way. A kludge by definition, you're trying to compare
bits and pieces of two things when what you *really* need to do is
compare the two things directly. File by file comparisons wont pick up on
a lot of the things that can cause disk burning to go wonky. You can in
fact even have an unreadable (by standard means) disk, with every byte of
the original data in tact. It could pass this sort of test with flying
colors, but be totally useless.

> I've never had any problems burning an .iso

Heh! You must not have been around very long. I remember back in the day,
making more coasters than I did usable CD's. A friend and I made so many
of them we took them to the shooting range on a regular basis. When the
technology was developing it was a *very* fragile process.

> (that was not my own
> mistake). It just works. :)

Yes. These days it usually it does. But what does that have to do with
the small percentage of the time that it does not? And how does that
solve the OP's problem?
From: Nomen Nescio on 25 Feb 2010 16:59
Sliverdick D. Barcodeboi wrote:

...

C'mere boy! Comeon! Sit! SIT!!

Good boy.

/me pats my pet idiot on the head and gives it a special treat.
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Emu Browser 2.4 (final free version) Program launcher
Next: A good opportunity to investment