Say you have about 2200 source code files. Spread across a handful of
subfolders and varying numbers of subfolders in each of those.
They were burned to a CD, and when you do a visual compare in Windows
Explorer between the files on the CD and the same files on a hard drive,
they appear to be the same. Same filenames, same file sizes,
modification dates/times.
However, if you run a file compare (say windiff), you notice that about
2/3rds of the files are coming up different.
Look in one of the subfolders. There are say 5 files: a.h (2k in size),
b.h (16 kb), c.h (10 kb), etc.
If you look at a file in the subfolder, say "a.h" (C language header
file) and open it in a text editor, you discover it's really the text
from "b.h". At least only the first 2kb of it. Open b.h and it's the
rest of the b.h file (resuming exactly where the previous file left
off), plus at the end, a bit of the top of c.h.
It's like the bytes are all there, but "shifted" onto the next sector.
The degree of "shifting" appears to be about 1680 bytes.
The CD was probably created with Roxio CD Creator version 6 (yeah, an
old version--it's what was installed on the PC). Don't have details on
the CD drive manufacturer. Under Windows 2000 or XP (don't know for
sure--the person that did the original burning is long gone from the
company).
Has anyone seen anything like this before? And if so, did you ever
figure out a reason why?
I remember a lifetime ago seeing similar issues on floppy disks when the
FAT table would get scrambled, but never on a CD.
I work in Compliance for a manufacturing company in a HIGHLY regulated
industry and I've inherited this problem. I now have to explain how it
happened to a (non-technical) regulator or the company faces potentially
huge fines. The regulator isn't buying just "the CD was corrupted when
it was created."
Ed Light wrote:
> I don't know if isobuster could help.
I'll check it out.
I need to explain how it happened, not rescue the data--we have multiple
copies of the data.
I looked at the isobuster website and it looks like this product allows
you to view a CD sector by sector. Maybe that will allow me to identify
the exact sector where the problem occurred. Unfortunately I only have a
copy of the CD to work from. I doubt the sectors are exactly the same.
It would be best if I could discover the root cause, and be able to
reliably duplicate the problem.
On Aug 1, 2:42*am, smh <nos...@nospam.org> wrote:
> . * * * * *--------------------------------------
> * * * * * * * Mike Richter, were you born with
> * * * * * *"Scam Artist" emblazoned on your face?
> * * * * * *--------------------------------------
> * * * * * * * * *http://tinyurl.com/gqnae
>
> *(No Mikey S-lickers have been able to prove ANY of the above )
> *(is a LIBEL -- despite Mikey claimed to have PROOF of libels!)
> '
>
>
>
>
>
> anonymousNetUser wrote:
>
> > Okay, here's the situation:
>
> > Say you have about 2200 source code files. Spread across a handful of
> > subfolders and varying numbers of subfolders in each of those.
>
> > They were burned to a CD, and when you do a visual compare in Windows
> > Explorer between the files on the CD and the same files on a hard drive,
> > they appear to be the same. Same filenames, same file sizes,
> > modification dates/times.
>
> > However, if you run a file compare (say windiff), you notice that about
> > 2/3rds of the files are coming up different.
>
> > Look in one of the subfolders. There are say 5 files: a.h (2k in size),
> > b.h (16 kb), c.h (10 kb), etc.
>
> > If you look at a file in the subfolder, say "a.h" (C language header
> > file) and open it in a text editor, you discover it's really the text
> > from "b.h". At least only the first 2kb of it. Open b.h and it's the
> > rest of the b.h file (resuming exactly where the previous file left
> > off), plus at the end, a bit of the top of c.h.
>
> > It's like the bytes are all there, but "shifted" onto the next sector.
> > The degree of "shifting" appears to be about 1680 bytes.
>
> If that were 2048 bytes, I would guess that file pointers are off by a
> sector (never minding why and how).
>
>
>
>
>
> > .
> > The CD was probably created with Roxio CD Creator version 6 (yeah, an
> > old version--it's what was installed on the PC). Don't have details on
> > the CD drive manufacturer. Under Windows 2000 or XP (don't know for
> > sure--the person that did the original burning is long gone from the
> > company).
>
> > Has anyone seen anything like this before? And if so, did you ever
> > figure out a reason why?
>
> > I remember a lifetime ago seeing similar issues on floppy disks when the
> > FAT table would get scrambled, but never on a CD.
>
> > I work in Compliance for a manufacturing company in a HIGHLY regulated
> > industry and I've inherited this problem. I now have to explain how it
> > happened to a (non-technical) regulator or the company faces potentially
> > huge fines. The regulator isn't buying just "the CD was corrupted when
> > it was created."
>
> > Thanks in advance for any assistance.
>
> I would get Total Commander, a shareware file manager, and then (1)
> compare hard disk and cd side by side, (2) compare two files by content,
> (3) view a file, etc.
>
> (1) Commands menu > Synchronize Dirs
> (2) Files menu > Compare By Content (after right-click files to compare)
> (3) F3 View
>
> http://www.ghisler.com/
>
> Also use IsoBuster to view cd sectors: Right-click, Sector View. This
> comes in handy to view Primary Volume Descriptor, directory entry, etc.http://www.isobuster.com/
>
> Hope you get some more information with the above two to aid your
> investigation.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Is the disk a UDF or Joliet?
If UDF, do very short files ( < 1K) display correctly.
Where the disks written in one session, or appended?
mscotgrove@aol.com wrote:
> On Aug 1, 2:42 am, smh <nos...@nospam.org> wrote:
>>
>>
>> anonymousNetUser wrote:
>>
>>> Okay, here's the situation:
>>> Say you have about 2200 source code files. Spread across a handful of
>>> subfolders and varying numbers of subfolders in each of those.
>>> They were burned to a CD, and when you do a visual compare in Windows
>>> Explorer between the files on the CD and the same files on a hard drive,
>>> they appear to be the same. Same filenames, same file sizes,
>>> modification dates/times.
>>> However, if you run a file compare (say windiff), you notice that about
>>> 2/3rds of the files are coming up different.
>>> Look in one of the subfolders. There are say 5 files: a.h (2k in size),
>>> b.h (16 kb), c.h (10 kb), etc.
>>> If you look at a file in the subfolder, say "a.h" (C language header
>>> file) and open it in a text editor, you discover it's really the text
>>> from "b.h". At least only the first 2kb of it. Open b.h and it's the
>>> rest of the b.h file (resuming exactly where the previous file left
>>> off), plus at the end, a bit of the top of c.h.
>>> It's like the bytes are all there, but "shifted" onto the next sector.
>>> The degree of "shifting" appears to be about 1680 bytes.
>> If that were 2048 bytes, I would guess that file pointers are off by a
>> sector (never minding why and how).
>>
>>
>>
>>
>>
>>> .
>>> The CD was probably created with Roxio CD Creator version 6 (yeah, an
>>> old version--it's what was installed on the PC). Don't have details on
>>> the CD drive manufacturer. Under Windows 2000 or XP (don't know for
>>> sure--the person that did the original burning is long gone from the
>>> company).
>>> Has anyone seen anything like this before? And if so, did you ever
>>> figure out a reason why?
>>> I remember a lifetime ago seeing similar issues on floppy disks when the
>>> FAT table would get scrambled, but never on a CD.
>>> I work in Compliance for a manufacturing company in a HIGHLY regulated
>>> industry and I've inherited this problem. I now have to explain how it
>>> happened to a (non-technical) regulator or the company faces potentially
>>> huge fines. The regulator isn't buying just "the CD was corrupted when
>>> it was created."
>>> Thanks in advance for any assistance.
>> I would get Total Commander, a shareware file manager, and then (1)
>> compare hard disk and cd side by side, (2) compare two files by content,
>> (3) view a file, etc.
>>
>> (1) Commands menu > Synchronize Dirs
>> (2) Files menu > Compare By Content (after right-click files to compare)
>> (3) F3 View
>>
>> http://www.ghisler.com/
>>
>> Also use IsoBuster to view cd sectors: Right-click, Sector View. This
>> comes in handy to view Primary Volume Descriptor, directory entry, etc.http://www.isobuster.com/
>>
>> Hope you get some more information with the above two to aid your
>> investigation.- Hide quoted text -
>>
>> - Show quoted text -- Hide quoted text -
>>
>> - Show quoted text -
>
> Is the disk a UDF or Joliet?
>
> If UDF, do very short files ( < 1K) display correctly.
>
> Where the disks written in one session, or appended?
>
> Are the disk CD-R or CD-RW?
>
> Michael
>
> www.cnwrecovery.com
Don't know. The person that created the disc left the company and their
PC has been reformatted and repurposed. The original disc is in the
hands of the regulator and cannot be examined.
We normally do only CD-R. That's about all I'm sure of.
> Don't know. The person that created the disc left the company and their
> PC has been reformatted and repurposed. The original disc is in the
> hands of the regulator and cannot be examined.
>
> We normally do only CD-R. That's about all I'm sure of.
It should tell you in isobuster, or your writing program.
--
Ed Light
Ed Light wrote:
>
>> Don't know. The person that created the disc left the company and
>> their PC has been reformatted and repurposed. The original disc is in
>> the hands of the regulator and cannot be examined.
>>
>> We normally do only CD-R. That's about all I'm sure of.
>
> It should tell you in isobuster, or your writing program.
I played with ISOBuster all day today. Pretty cool program--and less
then 5MB! Gotta love it when a programmer really knows what they're doing.
I know I always burn CD-R, but I can't vouch for what the person that
burned the original over a year ago did. And the copy the regulator sent
us in on a CD-RW.
> I know I always burn CD-R, but I can't vouch for what the person that
> burned the original over a year ago did. And the copy the regulator sent
> us in on a CD-RW.
I see -- there's no way to know about the original.
--
Ed Light
Ed Light wrote:
> anonymousNetUser wrote:
>
>> I know I always burn CD-R, but I can't vouch for what the person that
>> burned the original over a year ago did. And the copy the regulator
>> sent us in on a CD-RW.
>
> I see -- there's no way to know about the original.
Yeah... That's my problem.
Unless I can explain it, the regulator won't just accept that mistakes
happen and CDs can "go bad" or be burned bad.
We've since initiated new procedures in place to prevent this in the
future, but I was hoping maybe if I could provide anecdotal evidence of
something similar happening previously, it'd help. I've looked through
the support discussion groups on the Roxio website and this newsgroup
and the web in general, but so far, no concrete examples of something
similar happening to someone else.
I burned a dozen discs today, using different parameters and
intentionally trying to create a "bad" CD that looks similar. No luck
yet. Have a conference call with the regulator on Monday and then maybe
a trip to do a face to face meeting.
> Have a conference call with the regulator on Monday and then maybe
> a trip to do a face to face meeting.
Perhaps you can tell him that you have checked the copy with diagnostic
software and that you need the original to do likewise, otherwise
there's no way of knowing. Plus maybe you can get some support from the
isobuster guy. He is very helpful. He did an enhancement for me.
Trying to explain cause of CD corruption 
Linear Mode
