Varför skiljer sig dessa kopior åt?

Permalänk
Medlem

Varför skiljer sig dessa kopior åt?

Vad kan det finnas för anledning? Allokeringsstorleken eller något annat t ex att det är vissa attribut som inte kopierats korrekt?

Körde denna -> xcopy d:\Games r:\Games /c /h /e /r /k /y /i /q

Om man tittar på denna, som är gjord på exakt samma sätt och typ direkt efter eller innan, spelar ingen roll, så är det ingen skillnad på dom:

Visa signatur

gotta go fast

Permalänk
Medlem

Skall tillägga här, att jag bryr mig egentligen inte, har gjort såhär i hur många år som helst utan problem med spelen som kopierats över. Mest intressant varför just spelmappen som är så stor skulle skilja.

Visa signatur

gotta go fast

Permalänk
Medlem

Finns bara ett sätt att säkra detta - Hitta program som kan jämföra filerna på byte-nivå och markera det som avviker - och ja, det kommer att ta en stund att gå igenom 800 GB data totalt

Total commander har med sin funktion 'synkronisera mappar' möjlighet att göra det och även rekursivt i filträden och efteråt har man valet att genomföra synkningen eller inte och man kan se vilka filer som skiljer sig.

I total commander kan man också jämföra två filer separat även med olika namn och se skillnaden mellan dem som hexdumpar med sina ascii-värden.

---

Det jag tror som gör skillnad är olika gömda volymfiler som windows själv skapar och tex. hanterar och gömmer 'raderade' filer, versions-hantering av filer (dvs metadata för shadow copy), återställningspunkter mm. där och därmed kan vara olika stora beroende på hur moget filsystemet är (dvs. hur mycket man skrivit, läst och ändrat) - det finns en eller ett par sådana 'hemliga direktorys' som skapas på varje fysisk volym i windows och i princip inte syns förrän man läser disken med annan OS som inte är windows.

Permalänk
Vive la liberté!

Samma filsystem (NTFS, FAT32) på båda sidor?
Kan ev finnas Alternate Data Streams inbäddat i filerna som inte kopieras över med Xcopy.
https://nirsoft.net/utils/alternate_data_streams.html

Överlag är väl robocopy att föredra över xcopy i nyare Windows-versioner

Permalänk
Medlem

Normalt brukar inte R: och D: indikera att det gäller samma filsystem - men visst, sådant går också att trixa till om man vill.

Permalänk
Medlem

Det är samma filsystem och allt, så det är inte problemet. Men kanske streamsaken då, visste inte alls att det funkade så och det är intressant. Det är lite så att vissa spel har jag "aldrig" raderat, dom har kopierats från D: till nya D: från 1999 typ.

Att sitta och diffa 600GB är absolut inget jag tänker hålla på med heller

Trodde dessutom att xcopy var det nyare inte robocopy, vet inte varför jag trodde det (något med namnet). Kan börja köra robocopy i stället.

Visa signatur

gotta go fast

Permalänk
Medlem

Det handlar inte om Alternate Data Streams då dessa inte räknas med i storleken på filen.

xcopy inkluderar dessutom ADS.

Ärligt talat så tror jag faktiskt bara att någon fil ändrats i ursprungsmappen medan du gjorde kopieringen. Ibland är den enklaste förklaringen den mest sannolika!

Permalänk
Medlem
Skrivet av Hipshot:

Att sitta och diffa 600GB är absolut inget jag tänker hålla på med heller

Inte jobbigt tar bara lite tid

diff -r <path1> <path2>

Fast du får väl installera gnu diffutils om du inte har diff -- skiljer det sig sen så vet du att du har problem med hårdvaran.

Permalänk
Medlem

Enkelt.
Ett skript som listar alla filerna och storlekar.
Jämför.

Permalänk
Medlem
Skrivet av filbunke:

Enkelt.
Ett skript som listar alla filerna och storlekar.
Jämför.

fast då kollar man inte innehållet - NTFS stöder 'hål' i filer precis som de flesta Unix-filsystem vilket gör att en fil kan rapporteras stor men om man skriven med lseek i program fram och tillbaka (som torrent-nedtagningar) så förbrukas bara utrymmet från disken det som skrivs i filen fast den anges som tex. 4GB stor.

mao skall man vara helt säker så är det binär-jämförelser som bör göras.

Permalänk
Medlem
Skrivet av xxargs:

fast då kollar man inte innehållet - NTFS stöder 'hål' i filer precis som de flesta Unix-filsystem vilket gör att en fil kan rapporteras stor men om man skriven med lseek i program fram och tillbaka (som torrent-nedtagningar) så förbrukas bara utrymmet från disken det som skrivs i filen fast den anges som tex. 4GB stor.

mao skall man vara helt säker så är det binär-jämförelser som bör göras.

Ja, är det hål i filerna som kopieras så fyller väl xcopy ut det och då tar det större plats på disken där kopian ligger -- och diff ska visa att innehållet är identiskt.

Permalänk
Rekordmedlem

Doublekiller letar duplikatfiler och kan jämföra en fil bit för bit, det går ju att använda det eller liknade program baklänges och se vilka filer som blir kvar om man tar bort de som är bitexakta kopior.
http://www.bigbangenterprises.de/en/doublekiller/

Visa signatur

Ryzen 5 2400G, Asus ROG STRIX B350-F Gaming, 500GB Samsung 970EVO NVMe M.2 och en väldig massa masslagring. Seasonic Focus+ Gold 650W, Antec P 180 med Schyte o Sharkoon fläktar via en t-balancer, Tittar på en Acer ET430Kbmiippx 43" 4K
Främre ljudkanalerna återges via Behringer DCX2496, högtalare Truth B3031A, Truth B2092A Har också Oscilloskop, mätmikrofon och en Colorimeter.

Permalänk
Medlem
Skrivet av SAFA:

Ja, är det hål i filerna som kopieras så fyller väl xcopy ut det och då tar det större plats på disken där kopian ligger -- och diff ska visa att innehållet är identiskt.

Ibland behöver man skicka med flagga för att hål i filer skall bevaras även på kopia om dess filsystem som filerna landar på stöder det - annars är det du säger att hålen fylls med binära nollor vid kopiering och gör man diff mellan dessa så skall de ändå vara helt identiska.

Permalänk
Medlem
Skrivet av Hipshot:

Skall tillägga här, att jag bryr mig egentligen inte, har gjort såhär i hur många år som helst utan problem med spelen som kopierats över. Mest intressant varför just spelmappen som är så stor skulle skilja.

Igen aning vilket backup program du kör med, men ibland så har jag testat att uppdatera backupen igen efter den gått färdigt, då kan det vara några filer filer som uppdateras, fast den står inställd så det ska bli en exakt kopia, troligtvis någon bugg i programmet. Du kanske har råkat ut för något liknande ?