Vad orsakar att filkontrollsummor ändras efter kopiering via en SMB-delning?

SMB transporterar normalt filbytes oförändrade, så en kontrollsummeavvikelse innebär att det jämförda innehållet har ändrats, lästs inkonsekvent eller inte utgjorde samma dataström.

Avvikelsen kan bero på att källan hashades innan ett program hade skrivit klart, att en resursgren eller alternativ dataström jämfördes på ena sidan, att ett medie- eller säkerhetsprogram skrev om målet, att inaktuella klientcachedata lästes eller att lagrings- och transportfel uppstod. Det korrekta testet är att låsa källan, hasha båda filerna med samma verktyg och läge samt upprepa överföringen via en kontrollerad väg innan SMB får skulden.

Verifiera att båda kontrollsummorna omfattar samma fildata

Notera den exakta källsökvägen, målsökvägen, hashkommandot, algoritmen, binär- eller textläget samt tidpunkten då varje kontrollsumma skapades. Bekräfta att inget av kommandona läste en genväg, en symbolisk länk, en temporär fil eller en sidofil.

SHA-256-verktyget beräknar ett digestvärde från de byte som läses från den angivna filen. Referensen för sha256sum stöder användning av samma algoritm och anrop på båda slutpunkterna.

Om storlekarna skiljer sig åt ska du först felsöka en ofullständig eller ändrad kopia innan du jämför hashvärden. Om storlekarna matchar men hashvärdena skiljer sig åt fortsätter du med källans stabilitet, dataströmmens omfattning, lagringsläsningar och ändringar på målet.

Stoppa program som kan ändra källan under kopieringen

Stoppa databaser, nedladdningsklienter, virtuella maskiner, medieeditorer, synkroniseringsverktyg och alla program som skriver till källfilen. Skapa en ny kontrollsumma för källan först när filen är stängd.

Rsync-dokumentationen varnar för att filer bör flyttas till en övervakad källkatalog först när de har skrivits klart, eftersom en föränderlig källfil kan överföras inkonsekvent.

Jämför källans kontrollsumma omedelbart före och efter SMB-kopieringen. Om de två källhashvärdena skiljer sig åt är SMB inte den första orsaken; källan ändrades under testet.

Kontrollera oplocks, lokala skrivare och cachat filstatus

Lista öppna SMB-handtag och lokala processer som använder källan och målet. Var särskilt uppmärksam när samma resurs skrivs till samtidigt via SMB och direkt på NAS-värden.

Samba förklarar att opportunistiska lås gör det möjligt för en klient att cacha filändringar lokalt och synkronisera dem tillbaka till servern när det behövs. Dess modell för lås och oplocks visar varför samtidiga lokala SMB-skrivare måste kontrolleras under integritetstester.

Inaktivera inte oplocks på serversidan som första åtgärd. Stäng de konkurrerande programmen, öppna en ny session och upprepa kopieringen av en fil för att bevisa om samtidighet var inblandad.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separera filinnehåll från utökade attribut och alternativa dataströmmar

Bestäm om den förväntade kontrollsumman endast omfattar huvudfilens data eller ett arkiv som även innehåller resursgrenar, utökade attribut, alternativa dataströmmar, ACL:er och metadata. Använd samma omfattning på båda sidor.

ArchWiki beskriver utökade attribut som metadata som lagras separat från vanligt filinnehåll. Om dessa metadata förloras eller översätts kan en arkiv- eller pakethash ändras utan att huvuddataströmmens kontrollsumma ändras.

För macOS-filer ska du jämföra huvuddataförgreningen separat från eventuell resursgren eller AppleDouble-sidofil. Tolka inte en metadataavvikelse som ett bevis på att de primära filbytena har ändrats.

Använd ett kopieringsverktyg med återupptagning och loggning

Upprepa överföringen med en känd kopieringsmetod och ett nytt filnamn på målet. Spara loggen över återförsök, återupptagningar, överhoppningar och fel i stället för att förlita dig på en filutforskares förloppsdialog.

Microsoft definierar SMB som ett protokoll som gör det möjligt för program att läsa, skapa och uppdatera fjärrfiler. Dess modell för SMB-filåtkomst stödjer att en ändrad kontrollsumma betraktas som ett data- eller skrivarproblem, inte som en förväntad protokollomvandling.

Om en loggad kommandoradskopia matchar medan dra-och-släpp inte gör det, ska du jämföra programmet, beteendet vid återförsök, hanteringen av delvisa filer, virusskanning och efterbearbetning i stället för att ändra SMB-servern.

Jämför målet innan indexerare eller program skriver om det

Hasha målet omedelbart efter kopieringen medan det är stängt och innan medieskannrar, dokumentkonverterare, fotohanterare, antivirusprogram eller synkroniseringsklienter kan ändra det.

Oregon States Robocopy-guide betonar loggad kopiering som kan återupptas, vilket ger en tydligare gräns mellan att överföringen slutförs och att senare program ändrar målet.

Om målhashvärdet matchar omedelbart men ändras senare ska du identifiera den första processen som öppnar filen för skrivning. Den permanenta lösningen hör hemma i det programmets hantering av metadata, optimering eller synkronisering.

Upprepa testet över lagrings- och nätverksgränser

Kopiera samma stängda testfil lokalt på källans NAS, lokalt på målfilsystemet, via SMB från en annan klient och via den ursprungliga klienten. Hasha efter varje steg.

ZimaSpaces guide om att bevara metadata vid NAS-migrering ger en närliggande regel: innehållshashvärden och metadatafält måste valideras som separata godkännandekriterier.

Problemet är löst när en stängd källfil ger matchande hashvärden vid upprepade kopieringar och förblir oförändrad efter att efterkopieringstjänster har körts. Stoppa migreringen och skydda källan om avvikelserna följer en viss disk, styrenhet eller klient eller uppträder vid samma filposition varje gång.