Hitta duplicerade filer på NAS

Du gör det mer komplicerat än du måste.

Kör valfritt program på din dator och mounta enheterna på NAS (smb..) sen scannar du.

Bara dumt att köra det direkt på din NAS.

Du specificerar inte ditt OS på datorn.

För att leta duplikat under win är Doubblekiller pro svårslaget, gratisversionen är dock lite enerverande jobbig för de vill att man skaffar pro och av de jag provat är den bäst om inte perfekt men det är väl ingen för alla har inte alla funktioner man vill ha i ett och samma program ännu.
https://www.bigbangenterprises.de/en/doublekiller/

Kollade på czkawka och har inte gjort något riktigt test men märkte att man inte kan välja bit för bit jämförelse utan att det bara använder checksummor.

Det beror ju på vilken hash som används, men sannolikheten för att du ska få false positives är väldigt liten. Om du misstänker att två filer som rapporterats som lika inte är kan du lätt kolla det med ett annat verktyg. Det kommer inte vara många fall där olika filer får samma hash.

Det är ju standard, om den ska kolla bit-för-bit så kan man ju lika gärna bara skriver över filer utan att kolla. För det kräver samma mängd dataöverföring.

Det är väl för att undvika att skriva över filer med fel fil man ibland vill jämföra allt.

Har kört 'rmlint' länge - görs helst direkt på NAS:en eller servern om den går att installera eller går att kompilera upp i nasen.

en ren CLI-program som körs i terminal eller över ssh.

Förutom att ta bort dubbletter, sätta hårda länkar eller om det rullar på en BTRFS-filsystem - använda reflink (som hård länk men filen är en egen individ med egen inod och rättigheter och ägare som kan modifieras utan att det påverkar någon annan ställe i filträdet vilket det annars gör med hårda länkar, och inledningsvis delar den samma fysiska sektorer som orginalet den gjordes ifrån) då kan den även jämföra filträn och tex. ta bort alla filer som fins på den jämförda klientfilträdet om filerna också existerar på masterfilträdet men rör inga dubblettfiler på master-sidan.

Rmlint tar också hänsyn till lagringen så att läsningen inte ger överdrivet mycket läshuvudsförflyttning och försöker läsa smart på klientfilträdet och master-filträdet i anständig stora omgångar eller båda parallellt om de är inflätade i varandra - i början kan det upplevas att det trashar mycket på lagringen - men det är för att kartlägga filernas placering fysiskt på lagringsytan för att efter en stund försöka läsa dessa så linjärt i stora block som det går. Tex. om det är en master och en snapshot på BTRFS-filsystemet så läses sektorerna in fysiskt bara en enda gång då filerna i snapshot och i mastern är samma fysiska sektorer och klaras av samtidigt och inte i omgångar långt efter varandra.

Själva 'rmlint' tar inte bort några filer utan den genererar ett shellscript som gör jobbet vid en separat körning senare - och dessutom kollar att filen på masterträdet fortfarande är kvar innan filen på klientmappen raderas eller länkas om när scriptet senare väl körs - man har alltså chans att titta och editera i skriptet i en editor innan det körs - kan också levereras i andra format som json mfl. om man vill använda andra program som exekverar filraderingen eller granskar denna.

Rmlint använder hashar (fins flera olika att välja på som Blake2b (default) vilket är snabbare och nästa lika kryptografiskt starkt som tex. SHA256/512 vilket har betydelse på en enklare NAS som inte har fungerande HW-stöd för hashning) för att jämföra och kontrollerar på innehållet, inte filnamnet, och vid jämförelse mellan mappar så spelar det ingen roll i klientträdet filerna finns medans filerna i masterträdet rörs ej även om det finns multipla kopior inom masterträdet (vilket styrs enligt "klient1 klient2 ... // master1 master2 ..." efter kommandot med optioner, filmapparna kan alltså vara ett flertal på var sida av '//').

Den kan också spara hashar och tidstämplar med extension på var fil den går igenom vilket gör att en senare körning kan gå väldigt fort då den inte behöver hasha om filerna igen. Dessa följer med vid snapshot på BTRFS vilket gör att man kan snabbt gå igenom en snapshot mot mastern på enstaka minutnivå vid miljon filer och ett par TB storlek - sedan radera alla filer som är lika mastern i snapshoten och det som är olika är kvar i snapshoten.

Det är också anledningen att man bör köra programmet lokalt på NAS:en och inte via SMB/NFS då stödet för attribut mot ext4/BTRFS är från obefintligt till dåligt över nätverk - och sedan är det tveksamt att länkning med 'reflink' (på btrfs-filsystem) fungerar över nätverk.

Det finns en bra anledning till det. Blake3 är en välrenommerad kryptografisk hash som såvitt jag vet inte har några kända brister. Du kan i praktiken räkna med att om två filer har samma hash är det exakt samma fil, iaf inom överskådlig framtid. Om 100 år kanske man hittat kollisioner och någon elak person har smugit in två filer med samma hash på din NAS, vem vet, men då kanske czkawka också är uppdaterad att använda någon annan hash utan kända brister.

I nuläget är det större chans att vinna storvinsten på lotto tio veckor i rad än att du råkar ta bort en fil för att den har samma hash som en annan utan att vara identisk.

Det var väldigt jobb att få till en kollision med SHA1 på 2 PDF-filer med olika innehåll med många månaders beräkning med Googels dataresurser med i praktiken uppskattad entropi av 61 bitar (mot tänkta 80 bitar) för SHA1 - både Blake2/3 och SHA256/512 har ganska många fler bitar i entropi även om det skulle hittas ganska allvarliga brister i framtiden då man startar med 128 bitar i entropi och kan tappa mer än hälften av dem och det är fortfarande bättre än SHA1.

Det är fortfarande väldigt mycket dokumenthantering som använder SHA1 för att detektera skillnader i dokument fast den idag är klassad som depricated - tex. GIT använder fortfarande SHA1 för att hålla reda på filer och generationer och forkningar av projekt.

Däremot har man gjort vad man kan att få bort SHA1 i SSL/TLS, SSH samt olika CA-certifikat i och med att det har bevisats vara möjligt hackbart iom. att de hanterar förtroende, men den typen av hack på SHA1 är inget man får till hemma med sin spelrigg eller ens mindre företags serverparker...

Sannolikheten att två olika filer skulle ge samma hash-summa med blake2/3 eller SHA256 är så extremt liten att i praktiken kommer det inte att inträffa.