Gekopieerde files zijn subtiel anders

[BartS12]

Ik weet niet helemaal of mijn probleem met opslag technologie te maken heeft, dus wellicht is een ander forum beter. Dat gezegd hebbende...

Ik heb een vreemd probleem met een aantal files, specifiek RAW files uit een fototoestel. Deze heb ik lokaal staan, en (ooit) een backup kopie gemaakt naar mijn NAS (synology).

Bij het checken van de backup gaf mijn 'check programma' opeens aan dat enkele tientallen files (van de duizenden) niet identiek waren. Een visuele inspectie gaf geen problemen - beide plaatjes zien er prima uit. Maar bij het vergelijken van de ruwe data viel me iets aparts op. Op een flink aantal plekken is de ' byte waarde' precies 2 hoger! Daarmee bedoel ik dit, met links het origineel, en rechts de kopie. De verschillen zijn gehighlight:



Ook bij de andere files waar een verschil gevonden is, is precies dit het probleem. Zo af en toe zijn er gewoon wat bitjes ' omgevallen'

Het zijn dus RAW files (uit een Canon 70D), maar ik vermoed dat dit weinig met het probleem te maken heeft. Immers, ik heb gewoon met Windows explorer een kopie naar een andere harddisk gemaakt.

Hoe kan het dan, dat er telkens dezelfde 'fout' wordt gemaakt bij het kopieren...? Is dit een corrupte harddisk? Iets anders?

[Hahn]

Zijn deze verschillen niet onder andere doordat het nieuwe bestand bijvoorbeeld een nieuwe 'Created on [date]' heeft?

Een 100% identieke kopie kan in de praktijk eigenlijk nooit, alleen al doordat de create of edit date en de plek op de schijf anders zal zijn dan het origineel.

Wat is overigens het 'probleem', dan wel de 'fout'? Er zitten minuscule verschillen tussen de bestanden, maar zolang ze niet corrupt zijn en visueel niet verschillen, is er niet echt een probleem, toch?

[ Voor 26% gewijzigd door Hahn op 30-05-2020 00:17 ]

[heuveltje]

Hahn schreef op zaterdag 30 mei 2020 @ 00:16:
Zijn deze verschillen niet onder andere doordat het nieuwe bestand bijvoorbeeld een nieuwe 'Created on [date]' heeft?

Een 100% identieke kopie kan in de praktijk eigenlijk nooit, alleen al doordat de create of edit date en de plek op de schijf anders zal zijn dan het origineel.

Wat is overigens het 'probleem', dan wel de 'fout'? Er zitten minuscule verschillen tussen de bestanden, maar zolang ze niet corrupt zijn en visueel niet verschillen, is er niet echt een probleem, toch?

Lijkt mij dat dingen als create of edit in het filesysteem bijgehouden worden, en niet in de file ansich ?
als ik een filecompare tussen 2 kopieren doe, zie ik daar geen verschil in.

klinkt eigenlijk een beetje als bitrot. zolang dat een paar bits in een enorm raw bestand omvallen geloof ik ook wel dat je daar effectief weinig van merkt.

[Hahn]

heuveltje schreef op zaterdag 30 mei 2020 @ 00:21:
[...]


Lijkt mij dat dingen als create of edit in het filesysteem bijgehouden worden, en niet in de file ansich ?
als ik een filecompare tussen 2 kopieren doe, zie ik daar geen verschil in.

Goede vraag, terwijl ik m'n bericht aan het typen was bedacht ik me ook dat het wel apart is dat het maar in sommige bestanden voorkomt

[BartS12]

Tsja, het is deels nieuwsgierigheid - hoe kan zo'n subtiele fout zich zo consequent voordoen (honderden files, met elk op tientallen plekken telkens opnieuw dezelfde +2 bitfout) - en deels zorg: is deze harddisk 'rot'? Of is er iets anders aan de hand?

Er staat nog wel meer data op; en niet elke file blijft even goed werken als er bitjes omvallen...

[Erik Jan]

Wellicht ergens in een metadata sectie van het bestand, bijvoorbeeld Exif data of een kleine "preview" thumbnail? De laatste wil nog wel eens automatisch door software toegevoegd worden, zodat een volgende keer er sneller een preview beschikbaar is.

Om dat te bepalen moet je iets hebben wat dat specifieke RAW formaat begrijpt en de individuele blobs eruit kan knippen.

[Giesber]

BartS12 schreef op zaterdag 30 mei 2020 @ 00:27:
(honderden files, met elk op tientallen plekken telkens opnieuw dezelfde +2 bitfout)

Die +2 bitfout is wel goed opgemerkt: het lijkt altijd +2 of -2 te zijn. Dat betekent dat telkens de 7e bit in een byte flipt. Dit lijkt me een defect te zijn, en geen metadata ding. Alleen wordt het lastig om te zoeken wat er defect is: harde schijf, geheugenreepje, moederbord, kabel (aangezien het altijd dezelfde bit is is vooral een parallelle kabel verdacht, maar die zijn zeldzaam tegenwoordig), ...

Die eerste 2 zijn relatief simpel te controleren voor een tweaker: de harde schijf met een extended SMART test (al is daar nog een betere tool voor dacht ik), en het geheugen met Memtest86.

[Gomez12]

Kan het niet zo zijn dat je ze lokaal in een programma als LightRoom oid hebt geopend?

En dat dit programma met het openen ook deze inconsequenties heeft veroorzaakt doordat het simpelweg dacht fouten in RAW te herstellen...

Of wellicht dat je NAS wel software heeft om foto's te indexeren (Synology heeft bijv Moments) en dat die ze aangepast hebben.

Bitrot is redelijk uitgesloten als het alleen maar in je RAW-files zit, dan is het toch eerder een programma oid wat ze aangepast heeft (bewust of onbewust).
En ook niet alle RAW-formaten zijn perfect omschreven / niet alle camera's produceren perfecte RAW's volgens de specs, dus wellicht dat dit gewoon een autocorrectie is...

Giesber schreef op zaterdag 30 mei 2020 @ 00:54:
[...]
Die +2 bitfout is wel goed opgemerkt: het lijkt altijd +2 of -2 te zijn. Dat betekent dat telkens de 7e bit in een byte flipt. Dit lijkt me een defect te zijn, en geen metadata ding. Alleen wordt het lastig om te zoeken wat er defect is: harde schijf, geheugenreepje, moederbord, kabel (aangezien het altijd dezelfde bit is is vooral een parallelle kabel verdacht, maar die zijn zeldzaam tegenwoordig), ...

Tja, een defect wat enkel optreed in 1 type bestanden?
En dat het het steeds de 7e bit zou zijn kan ook gewoon puur zijn omdat het in het formaat ergens specifiek voor staat.

[ Voor 33% gewijzigd door Gomez12 op 30-05-2020 00:59 ]

[Q]

Ik adviseer om een nacht lang een metest te draaien op je computer.

https://www.memtest.org/

Misschien is het een rotte plek in je RAM.

Als je een Mac hebt moet je zelf even naar een equivalent zoeken.

[ Voor 19% gewijzigd door Q op 30-05-2020 01:11 ]

[Thralas]

Giesber schreef op zaterdag 30 mei 2020 @ 00:54:
Dat betekent dat telkens de 7e bit in een byte flipt.

code:

Tweede bit. Little endian.

Dit lijkt me een defect te zijn, en geen metadata ding.

Eens.

Alleen wordt het lastig om te zoeken wat er defect is: harde schijf, geheugenreepje, moederbord, kabel (aangezien het altijd dezelfde bit is is vooral een parallelle kabel verdacht, maar die zijn zeldzaam tegenwoordig), ...

Bad RAM is altijd een goede kanshebber. Vervelend dat er meerdere systemen bij betrokken zijn, dat maakt het zoeken naar een speld in een hooiberg.

Naast memtest even nagaan of een van de betrokken systemen onverklaarbare crahes (applicaties, OS) ervaart.

Soms zijn dit soort issues behoorlijk subtiel: ik had eens een systeem met hele sporadische crashes, maar bij het downloaden van een groot bestand waren geen twee files hetzelfde: toch bad RAM..

SATA is seriëel, en heeft daarnaast gewoon checksums. Van een (moderne) harddisk heb ik ook nog nooit vernomen dat 'ie rotte data teruggeeft, hoogstens een bad sector.

[ Voor 8% gewijzigd door Thralas op 30-05-2020 01:13 ]

[Q]

Precies. Ik zou dezelfde bestanden even met een andere (leen) computer heen en weer kopiëren. Als je dan precies hetzelfde probleem hebt is je nas waarschijnlijk het probleem. Zo niet, dan is je computer waarschijnlijk het probleem.

[White Feather]

Ik zou eerst nu eens een kopie maken en die vergelijken ipv allerlei conclusies trekken over Ram van Nas of PC zoals hier aangegeven wordt.

De backups zijn van “ooit” Wie weet welke programma’s er in die tussentijd aan hebben gezeten.

De kans dat het Ram is en het verschil iedere keer op dezelfde plek terug komt met dezelfde waarde is bijna nihil, net als problemen met schijven of netwerkkaarten.

Er zou dan structureel iets fout moeten gaan op specifiek die plek, terwijl het systeem zelf helemaal stabiel is.

[Jimster]

Hoe heb je ze gekopieerd vanaf je camera? Met mijn goedkope Ali USB 3 card reader raken bestanden corrupt als ik via een USB 3 poort kopieer, met een USB 2 poort werkt alles prima.

[technorabilia]

Misschien kun je nog voorzieningen treffen voor de toekomst.

https://blog.synology.com...-against-data-corruption/

Edit:
Data scrubbing. Zie link.

[ Voor 11% gewijzigd door technorabilia op 30-05-2020 09:47 ]

[jan99999]

Met een par2 bewerkte file kun je snel checken of iets veranderd is, na het kopiëren.

Backups altijd maken met backup software, en met controle achteraf, dus een compare met origineel en kopie.

Vroeger heb ik eens gehad dat 1 op de 10 files beschadigd was, na lang zoeken was dit een netwerk kaart driver die niet goed was. En op elke 10e file beschadigd in de backup.

Op de nas heb je daar raid gebruikt, deze doet elke maand een controle op je file systeem, heb je daar alarm gekregen?

[CH4OS]

@jan99999 par2 is een goede optie, mits je het bestand vanaf een betrouwbaar systeem kan maken en dat weet je nu niet welke dat is.

[aawe mwan]

Door de rare indeling die je gebruikt hebt voor je screenprint valt het niet op, maar alle bitfouten lijken te zitten op een adres dat eindigt op een x1 of op een x9. Oftewel ze zitten altijd een veelvoud van 64 bits (8 bytes) van elkaar af.

Daarom denk ik dat de fout veroorzaakt is door een chip of module die de data verwerkt in blokken van 64 bits. Meestal werkt een NAS nog met 32-bit technologie en een PC met 64-bit technologie.

Maar je hebt nog niet verteld welke apparatuur je precies gebruikt, dus verder blijft het bij speculeren.

Het is een Synology NAS, dus je kunt ook een kopie maken op de NAS zelf (zonder computer te gebruiken). Je kunt Synology ook "intern" een MD5 van het bestand laten berekenen, zo kan je zien of het bestand ook inderdaad verkeerd op de schijf staat, of dat het nu alleen verkeerd overgehaald wordt naar jouw PC.

Het probleem reproduceren als het in je PC zit is heel moeilijk, want dan is het maar een heel klein gedeelte van het geheugen dat soms niet goed werkt. Daarvoor moet je echt een keer een hele nacht memtest laten draaien. Maar wel heel belangrijk om te doen want nu valt het probleem toevallig een keer op, maar meestal niet.

[ Voor 37% gewijzigd door aawe mwan op 30-05-2020 10:19 ]

[BartS12]

Dank allemaal voor de antwoorden, het beeld begint me heel aardig duidelijk te worden. Hoofdverdachte: geheugen en/of geheugencontroller. Even wat inhoudelijke reacties:

Ik zou eerst nu eens een kopie maken en die vergelijken ipv allerlei conclusies trekken over Ram van Nas of PC zoals hier aangegeven wordt.

Dezelfde files nog een keer kopieren zorgt wel voor een identieke kopie. Althans, ik heb er handmatig een stuk of 10 geprobeerd. Het lijkt dus echt ' statistiek', soms gaat het mis.

Hoe heb je ze gekopieerd vanaf je camera? Met mijn goedkope Ali USB 3 card reader raken bestanden corrupt als ik via een USB 3 poort kopieer, met een USB 2 poort werkt alles prima.

Het probleem is pas daarna ontstaan. Ik heb een file vanaf SD kaart naar harddisk gekopieerd; en daarna een kopie daarvan weer naar NAS. Het verschil zit tussen de ' harddisk versie' en de 'NAS versie'.

Soms zijn dit soort issues behoorlijk subtiel: ik had eens een systeem met hele sporadische crashes, maar bij het downloaden van een groot bestand waren geen twee files hetzelfde: toch bad RAM..

Dit is wel spot-on... Ik heb inderdaad zo af en toe wel BSODs; en nu ik er zo over nadenk, misschien de laatste tijd nog wat meer dan vroeger. En dat downloaden van een groot bestand - ja! Recent uit (professionele) bron een groot RAR bestand moeten downloaden; was keer op keer corrupt. ' Zomaar'. Pas bij de 5e of 6e keer downloaden was het opeens wel goed. Nooit de connectie gemaakt met dit issue...

Wel recent een keer kort een memtest laten draaien; die vond niks bijzonders. Maar ik zal dat nu toch maar eens een keer langdurig laten draaien.

Daarom denk ik dat de fout veroorzaakt is door een chip of module die de data verwerkt in blokken van 64 bits. Meestal werkt een NAS nog met 32-bit technologie en een PC met 64-bit technologie.

Ik draai (nog steeds...) Win7 Ultimate, 64 Bits. En de Nas is een Synology Ds218+.

[Q]

Dit klinkt 100% als rot geheugen, met al die extra symptomen. Ik zou die memtest echt een hele nacht laten draaien.

Maar er is nog een andere (mogelijk snellere) truck: trek geheugen modules uit je systeem en kijk of het probleem zich dan voordoet. Niet super handig, maar helpt eventueel bij bepalen welke module stuk is.

Ik denk dat een lange memtest (met al het geheugen geinstalleerd) jou precies gaat vertellen welke dimm(s) stuk zijn.

Let op: al je data die je de afgelopen periode hebt aangeraakt (geedit) kan corrupt zijn. Corrupte data kan dus ook in je backups komen.

Check kritische bestanden op een 'veilig' systeem of zo snel mogelijk nadat je het rotte reepje even uit je pc hebt gehaald.

[ Voor 46% gewijzigd door Q op 31-05-2020 23:20 ]

[BartS12]

Nou, voor de volledigheid - het is 'case closed'.

Memtest86 had er minder dan 5 minuten voor nodig, om tot een duidelijk oordeel te komen; de test werd afgebroken wegens ' teveel fouten' (de memtest van windows zelf, mdsched, vond overigens met een nacht lang draaien helemaal niks...). En inderdaad, in het 'bit pattern' waar de fouten gevonden werden, zat telkens een +2 verschil.

Geheugen vervangen door 2 andere reepjes, en memtest draait foutloos. De vergelijking tussen oude en nieuwe files gaf nog steeds aan dat er verschillen waren, dus conclusie: de files zijn echt anders (en het was geen issue dat tijdens het vergelijken op trad !)

Opnieuw kopieren van 1000 RAW files van disk naar NAS, en opnieuw vergelijken. Resultaat : alle 1000 identiek.

Case closed - rot geheugen. Nu eens kijken wat de 'lifetime warranty' van Corsair doet met DDR3 geheugen uit 2012

[Q]

Gefeliciteerd, het raadsel is opgelost. Succes met de RMA

[Navi]

Mooi verhaal!

Dit is waarschijnlijk een mooi voorbeeld waarom kritieke systemen zoals servers voorzien worden van ECC geheugen, om dit soort dingen te voorkomen? (Of op zijn minst te corrigeren of detecteren)

Overigens apart en tricky dat de bestanden nog prima te openen waren en geen zichtbare fouten vertoonden.

[ Voor 20% gewijzigd door Navi op 02-06-2020 20:04 ]

[Q]

Navi schreef op dinsdag 2 juni 2020 @ 20:02:
Mooi verhaal!

Dit is waarschijnlijk een mooi voorbeeld waarom kritieke systemen zoals servers voorzien worden van ECC geheugen, om dit soort dingen te voorkomen? (Of op zijn minst te corrigeren of detecteren)

Er worden geen servers verkocht zonder ECC geheugen. Het is ergens een gotspe dat ECC niet standaard is op de laptop/desktop. Je ziet het helaas alleen bij (high-end) workstations.

[FreakNL]

Volgens zijn er wel server met non ecc geheugen... Maar das wel MKB spul, in het serieuze spul is het allemaal ECC