 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsPC HardwareCPUMotherboardsVideo CardsStorageNetworkingPeripheralsBrand Name Systems Related Topics Video GamesWindowsMS Server ProductsMS OfficeMore Topics ... |
Hardware Forum / Storage / CD and DVD / August 2008Trying to explain cause of CD corruption
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. 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 don't know if isobuster could help.  SignatureEd Light Better World News TV Channel: http://realnews.com Bring the Troops Home: http://bringthemhomenow.org http://antiwar.com Iraq Veterans Against the War: http://ivaw.org http://couragetoresist.org Send spam to the FTC at spam@uce.gov Thanks, robots. > 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. Thanks for the input! . -------------------------------------- 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!) ' > Okay, here's the situation: > [quoted text clipped - 20 lines] > 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 [quoted text clipped - 16 lines] > > 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. > . -------------------------------------- > Mike Richter, were you born with [quoted text clipped - 74 lines] > > - 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 >>> Okay, here's the situation: >>> Say you have about 2200 source code files. Spread across a handful of [quoted text clipped - 64 lines] > > 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. SignatureEd Light Better World News TV Channel: http://realnews.com Bring the Troops Home: http://bringthemhomenow.org http://antiwar.com Iraq Veterans Against the War: http://ivaw.org http://couragetoresist.org Send spam to the FTC at spam@uce.gov Thanks, robots. >> 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 [quoted text clipped - 3 lines] > > 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. SignatureEd Light Better World News TV Channel: http://realnews.com Bring the Troops Home: http://bringthemhomenow.org http://antiwar.com Iraq Veterans Against the War: http://ivaw.org http://couragetoresist.org Send spam to the FTC at spam@uce.gov Thanks, robots. >> 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. support (at) isobuster.com or the web form: http://isobuster.com/isobustersupport.php SignatureEd Light Better World News TV Channel: http://realnews.com Bring the Troops Home: http://bringthemhomenow.org http://antiwar.com Iraq Veterans Against the War: http://ivaw.org http://couragetoresist.org Send spam to the FTC at spam@uce.gov Thanks, robots. >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. Burned CDs *definitely* "go bad", you can find plenty of research and anecdotal evidence about that on the web. SignatureN anonymousNetUser wrote... >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." The damage was done. Could an EXPLAINATION excuse your company from her fault? I don't think so. Your company has hired someone incompetent, someone skipping the CD verification (by windiff or other means) with the source right after burning a CD. The only explanation you can give is to admit the fault where your company does not hold a process in place, to enforce source codes verification right after archiving them to CD's. > anonymousNetUser wrote... > [quoted text clipped - 7 lines] > Could an EXPLAINATION excuse your company from her fault? > I don't think so. I agree. However, the regulator has asked for an explanation. In this industry, when a regulator asks for something, you provide it. > Your company has hired someone incompetent, someone skipping > the CD verification (by windiff or other means) with the source > right after burning a CD. And thankfully, the guilty party is no longer with the company (not for this, but for other infractions far worse). > The only explanation you can give is to admit the fault where > your company does not hold a process in place, to enforce source > codes verification right after archiving them to CD's. To be fair, the process was never documented until I came along. And prior to this incident, no one in the company did any sort of verification. The company's already admitted fault for not having a better process in place at the time. (The original CD was created over a year ago.) But as I said, the regulator doing the investigation insists on an explanation. As far as the software going into our machines--it's on EPROMs, so EPROM samples are provided to all regulators. Interestingly, this is the only regulatory body that accepts the CD copy as the "official" copy--all others accept the EPROM sample supplied with the submission to the "official" copy and don't hold a bad CD at fault. anonymousNetUser wrote... >I agree. However, the regulator has asked for an explanation. In this >industry, when a regulator asks for something, you provide it. I have had experience burning CD archives and then found out (by windiff) that some resultant CDs have had cyclic redundent errors. The only explanation I could guess, for myself, was that there may be small electrical interfence during the burning processes that make a byte or more of data not burning correctly during the burning process. God know what the cause was (for my clyclic redundent errors.. But even as a hobbist, I windiff my CD archive right after the CD is burnt. So, as a company delivery software, why would there be no verfification in place? >To be fair, the process was never documented until I came along. And >prior to this incident, no one in the company did any sort of verification. No one blame you. So, "to be fair" should be addressed between your company and the customers. It is only fair for your company to pay some sort of panelty w.r.t. the customers who have sufferred due to the faiult of your company. >The company's already admitted fault for not having a better process in >place at the time. (The original CD was created over a year ago.) > >But as I said, the regulator doing the investigation insists on an >explanation. If I were you, I would try to "simulate" a faulty CD burning on a PC similar to the one which the fault was created a year ago. Say, use Roxio to burn a sample of the source codes over and over again, 500 times, 1000 times maybe, and hofully creating a faulty CD as the one held by the regulator. Maybe burning 1000 CD's, and find out that there may exist one or more CD's having cyclic redundent error, just to "explain" to the regulator that CD burning is not 100% error proof. And due to lock of verification process a year ago, such faulty CD was leaked out of your company. A good CD will become bad (as your symtom description) by storage for a year ? I don't believe it. I have CD's burnt 3 years ago and I could still retrieve data from my archieves I windiff'ed the majority of them whenever I created them, except for movies copies. > anonymousNetUser wrote... > >I agree. However, the regulator has asked for an explanation. In this [quoted text clipped - 39 lines] > archieves I windiff'ed the majority of them whenever I created them, > except for movies copies. Without seeing a disk if is very difficult to speculate the reason for failure. It appears that it may be a logical failure, rather than physical, as files can be read, but the incorrect data is restored - ie a mixture of two files. You say that 2/3 of your files have problems in WinDiff. Does this mean that 1/3 of your files are 100% correct, or on each file 1/3 of the file incorrect. If 1/3 are correct, are they in a specific area of the disk, and has the disk been appnded to? As you only have the copy, it is difficult to know how accurate it is. I have just looked through my recovery notes and once I had a NTFS hard drive where many sectors had been shifted by just 36 bytes. On this basis, it is possible that the original hard drive had the problem and there is nothing wrong with your CD. I have also had memory chips (FAT16) where areas of data have been shifted. Camera chips often have very odd, unexplained problems. Recovery is normally possible by taking an image of the media and inserting or cutting to get sectors back to the correct location. Michael www.cnwrecovery.com >> anonymousNetUser wrote... >>> I agree. However, the regulator has asked for an explanation. In this [quoted text clipped - 61 lines] > Michael > www.cnwrecovery.com Michael, Interesting stuff. Thanks for contributing. It's a bit of a moot point now. Had a phone conference with the regulators on Monday and finally convinced them that the CD really was corrupted and that our company wasn't trying anything shifty. The incident is considered closed now. (Thank goodness--I was really sweating it there for awhile. I'm willing to own up to my own mistakes, but it always makes me nervous when I have to explain other people's failings.) > It's a bit of a moot point now. Had a phone conference with the > regulators on Monday and finally convinced them that the CD really was > corrupted and that our company wasn't trying anything shifty. Nice! SignatureEd Light Better World News TV Channel: http://realnews.com Bring the Troops Home: http://bringthemhomenow.org http://antiwar.com Iraq Veterans Against the War: http://ivaw.org http://couragetoresist.org Send spam to the FTC at spam@uce.gov Thanks, robots. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.