Vad gör Verifiera skiva faktiskt efter bränning för att verifiera data?

Funktionen "verifiera skivan" är utmärkt för att se till att din nybrända skiva visade sig bra, men hur exakt fungerar det? Dagens SuperUser Q & A inlägg har svaret på en nyfiken läsarens fråga.

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Foto med tillstånd av kobolt123 (Flickr).

Frågan

SuperUser-läsaren user1301428 vill veta hur skivor är verifierade efter att de bränts:

Vad kontrollerar skivan efter bränning faktiskt att verifiera data? Jag antar att det är någon form av jämförelse mellan de ursprungliga filerna och filerna som har bränts på skivan, men vet någon hur det verkligen görs på en låg nivå?

Jag menar, skapar det en hash av källan och destinationsinnehållet, jämför dem då? Om så är fallet lagras det hash för det brända innehållet i RAM? Eller sparar den den i en tillfällig fil på hårddisken? Finns det en loggfil av vad som händer?

Bara nyfiken på att veta exakt hur den här funktionen fungerar. Och jag hänvisar till Windows Image Burner.

Hur fungerar skivverifieringsprocessen?

Svaret

SuperUser bidragsgivare Frank Thomas och Synetech har svaret för oss. Först upp, Frank Thomas:

Kolla in dessa MSDN-sidor på Windows API för IBurnVerification-gränssnittet och IMAPI_BURN_VERIFICATION_LEVEL enum.

För dataskivor ser det ut som i snabbläge det kontrollerar inte hela skivan, bara ett urval av sektorer. Det ser då till att API: n kallar READ_DISC_INFO och READ_TRACK_INFO lyckas mot den nya skivan.

För fullständig verifiering utför den ovanstående kontrollerna, och sedan bränns en fullständig kontrollsumma för den sista sessionen på den nya skivan mot en kontrollsumma beräknad på minneströmmen. Kontrollsummorna måste lagras i ram, men de är sannolikt kortlivade värden. Observera att jämförelsen är mot skivavbildningen i RAM, inte källmediet själv, så om källdatan inte läste korrekt kommer den att skrivas felaktigt. Verifiering kommer inte att upptäcka detta.

För musikskivor fokuserar den på att läsa READ_TRACK_INFO och skivavdelningen, men utförs inte en checksumberberäkning. Det finns inget fullständigt verifieringsläge för musik.

Följd av svaret från Synetech:

Frank förklarade trevligt den Windows-specifika verifieringen. Jag kommer att ge ett mer generellt svar.

• Vad verifierar skivan efter bränning gör faktiskt för att verifiera data?
• Jag menar, skapar det en hash av källan och destinationsinnehållet, jämför dem då? Om så är fallet lagras det hash för det brända innehållet i RAM? Eller sparar den den i en tillfällig fil på hårddisken? Finns det en loggfil av vad som händer?

Det är verkligen ett sätt att en jämförelse kan genomföras: hash en fil (förhoppningsvis med en tillräckligt stor läsbar låg risk för kollisionsalgoritm), upprepa den andra och jämföra hash. Om det är hur en verifiering genomförs, så kommer du att kunna se drivlampan för en stund och sedan blinkar CD / DVD-lampan ett tag.

Ett annat sätt att genomföra verifieringen är att läsa ett block med en fil, sedan samma block från den andra filen, jämföra dem och upprepa sedan tills filens slut är uppnått. I det här fallet ser du LED-lamporna på de två enheterna växlar fram och tillbaka.

Självklart, om hårddisken och den optiska enheten inte har lysdioder, så blir det inte så uppenbart. Men du kan fortfarande se den med något som ProcessMonitor eftersom det kommer att logga en serie av läsningar från den ena, den andra, antingen i en enda, stor burst eller alternerande, små sprickor.

• Jag antar att det är någon form av jämförelse mellan de ursprungliga filerna och filerna som har bränts på skivan, men vet någon hur det verkligen görs på en låg nivå?

Egentligen gör allt det egentligen att spola drivcachen så att jämförelsesfunktionen läser data från den aktuella skivan istället för från minnescachen. Självfallet är detta ett kritiskt steg, för om verifieringen görs från cacheminnet, representerar den inte vad som verkligen är på skivan, så korruption kan lätt gå igenom.

Du kan se om en jämförelse görs från enheten eller från cacheminnet i RAM genom hur snabbt det uppstår. Om du manuellt gör en enkel jämförelse (det vill säga med WinDiff, WinMerge eller genom att ha hashing dem med ett hashverktyg) kommer du att märka att jämförelsen sker mycket snabbare än förväntat eftersom det läser filerna från minnescache. Du måste spola cacheminnet för att tvinga det att läsa från den aktuella skivan. För optiska enheter (och andra flyttbara media som flash-enheter och minneskort) är det enkelt att skicka ut enheten, men det är inte så enkelt för hårddiskar (det brukar dock inte spelas in eftersom ny kopia är den du vill testa).

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.