datafeil (sirkulerende overflødighetskontroll, CRC)

[Josten]

Når jeg prøver å innstalere Unreal2 kommer denne feilmeldingen. Det er visstnok noe galt med data3.cab. Noen som vet hva årsaken er? Cden er svakt ripet opp, men ingen store riper.

[Eloquence]

CRC = Cyclic Redundancy Control.

 

Det er det det står det er - datafeil. En fil kan ikke leses. CRC er en metode for å kalkulere en "sjekksum" (et tall som sier om filen er komplett eller ikke). I dette tilfellet stemmer ikke det lagrede CRC-tallet med det kalkuerte CRC-tallet, og Unreal-cd'en din er nå en fin men dyr ølbrikke.

 

Eloquence

[FreeBSD]

Og det er ganske sikkert svaret, Josten.

 

Et CAB-arkiv, såvel som andre komprimerte arkiver er følgelig meget utsatt for feil. Hvis lagringsmediet er skadet på noen måte, er dette den eneste løsningen jeg kan se.

 

Har du mulighet, brenner du ut en ny ISO-fil - eller spør butikken om å få bytte inn CDen i en ny. Noen yter den slags service.

[Ernie]

eller spør butikken om å få bytte inn CDen i en ny. Noen yter den slags service.

hvor har du fra at han har orginal cd?

[Jazzcat]

CRC = Cyclic Redundancy Control.

 

Det er det det står det er - datafeil. En fil kan ikke leses. CRC er en metode for å kalkulere en "sjekksum" (et tall som sier om filen er komplett eller ikke). I dette tilfellet stemmer ikke det lagrede CRC-tallet med det kalkuerte CRC-tallet, og Unreal-cd'en din er nå en fin men dyr ølbrikke.

 

Eloquence

 

CRC = Cyclic Redundancy Check

[ØysteinI]

CRC, eller Cyclic Redundancy Check er en måte å oppdage bit-feil i datastrømmer eller filer (Med bitfeil menes at en eller fler tilfeldige 1'ere har blitt oppfattet som 0 og motsatt) og denne metoden er i bruk i nær sagt alle plasser hvor data flytter på seg. Nettverk, fra CD, tape'r osv osv ... Det sier seg jo selv at en fil hvor en eller flere 1'ere har blitt 0 og omvendt, så går dette raskt til helsikke...

 

Hele greia går ut på å ta alle dataene som skal sendes, dividere den binært med et spesielt binært polynom (tall). Dette tallet er : G(x)=x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x1+1, eller skrevet binært 0000.0100.1110.0001.0001.1101.1011.0111. Etter å ha dividert gjennom hele datastrømmen, vil man få en rest på noen bit. Disse sendes så med dataene over til mottager som en del av dataene.

 

Eks:

0100.1011.0101: <binært polynom> = rest

Det som blir sendt er da 0100.1011.0101rest

 

På mottagersiden blir så hele datastrømmen inkl. resten dividert mot det samme polynomet. Hvis det IKKE har vært noen feil i overføringen skal resten bli nøyaktig 0. Om det har vært en eller flere feil, så vil svaret IKKE bli 0.

 

Eks:

Mottat data : 0100.1011.0101rest

Hvis alt er rett; er 0100.1011.0101rest : <polynom> = 0

 

Det er ingen måte å finne ut hvilke/hvilket bit som er feil, så alle dataene må sendes på nytt. Videre kan heller ikke CRC oppdage et feilmønster som er identisk med polynomet selv.

 

Eks:

Om polynomet hadde vært 10011, ville ikke CRC vært i stand til å oppdage om det forekom et feilmønster som var slik "feil-rett-rett-feil-feil" ett eller annet sted i fila/datastrømmen. Den berømmelige resten ville blitt 0 og dataene godtatt som "Ok" ... men det er dermed ikke sagt at fila hadde funka.

 

Så til trådstarter: om det er en CRC-feil på fila du vil bruke, så er det ingen annen vei utenom å få tak i en ny kopi av fila. Sorry, men sånn er det.

[tvangsgreie]

Når man skal brenne CDer eller DVDer, og det er litt ledig plass, er det lurt å fylle opp resten av plassen med PAR2-filer. Om man har 20 MB med PAR2-data, og man får en ripe som gjør at 19 MB ikke er lesbare, vil man kunne bruke PAR2-filene til å fikse de ødelagte dataene. Det står mer om det på parchive.sourceforge.net.