[PHP] tips och trick som gör att man kan kolla om ett filmklipp är likt ett annat?

Du kan använda en hash-funktion, t.ex. SHA-1/MD5 för att beräkna om samma fil redan laddats upp. Exempel på hur du kan göra finns här. Som du ser så används en funktion, md5_file, som jobbar direkt med en fil. Givetvis vill du spara värdet på uträkningen i databasen så att du kan se om filen redan finns när den laddats upp.

Syfte att spara diskplats ??

(några hann före...)

Spara hash-summa på filerna och stoppa i databas när de laddas upp och försöker man med samma igen (även med annan filnamn) så neka och meddela att den finns redan uppladdad och den nyss uppladdade raderas - om möjligt försöker man med javascript få browsern att hasha igenom filen lokalt innan den sänds upp till webservern för att minska både blockering av port i webservern med uppladdning och minska beräkningslasten i webservern.

Dock måste man hantera situationen om flera olika användare sparar upp samma bilder/filmer så att det inte blir stopp för att någon annan redan kört upp samma bild/film och att hashsumman också försvinner i databasen när sista exemplaret av filen raderas.

Använd helst inte md5 eller SHA1 utan hellre blake2b eller långsammare SHA256 då md5 och SHA1 numer anses svaga hash med för hög risk för hashkrock och med SHA1 så finns det redan 2 pdf-filer med samma SHA1 men olika innehåll skapad av Google för att bevisa SHA1:s otillräckliga styrka och det var påfallande många dokumenthanteringssystem som krashade mycket elakt till regelrätta totala haverier när folk började skicka in just dessa två dokument i systemet för några år sedan - att somliga fick tom. förbjuda pdf-dokument som giltig dokumentformat... även GIT var i ropet då de också använder SHA1 men där är användningen på sådan sätt att det inte blev några allvarliga konsekvenser i sin inre struktur utan filen med samma hash-värde man försök sända upp helt enkelt inte accepterades.

Så vilken lösning du än väljer - prova med dessa 2 olika pdf med samma SHA1 hash och se att det hanteras rimlig - för någon kommer att göra det förr eller senare

---

Att fånga 'liknande' filmer/bilder är helt annan scoop och det är sådant som google och andra stora sökmotorer och sociala medier sysslar med i stora dataparker och mycket avancerade icke publika algoritmer som hela tiden förbättras och putsas på

---

Eller så sköter man det tyst i bakgrunden på servern med att göra fil-mässig deduplikation så att lika filer hårdlänkas och om det är på BTRFS att de reflinkas för att spara diskplats och det finns flera program kan göra sådant, men tex. 'rmlint' kan både hårdlänka dubbletter eller i BTRFS filsystem göra reflink på filerna som den hittar när den går igenom filträden och den går inte på filnamnen utan tittar på innehållet och identifierar lika filer även under olika filnamn och olika platser i filträdet. - rmlint i sig tar inte bort eller deduplicerar filer - den skapar en bash-script som gör jobbet när den senare körs.

btrfs 'reflink' eller cloning är att föredra framför hård länk då filen är 'unik' och kan modifieras var och en utan att det slår på motsvarande referenser på andra ställen i filträdet medans Unix/linux hårda länkar pekar de olika namnen på samma 'inod' (som hantera filkroppen) vilket innebär att om man via ett filnamn modifierar filen så kommer modifikationerna också slå på de andra referenserna från andra filnamn i filträdet - och modifikation kan vara så enkelt som rättigheter då det lagras i själva inoden och är lika för alla filnamn som refererar till inoden.

För närvarande är det bara BTRFS och XFS som stöder 'reflink' i filsystem - ZFS 'borde' ha den men ingen har implementerat detta i open ZFS fast det har gått 10 år minst fast de senare stängda kommersiella ZFS har reflink implementerat.

Programmet rmlint kan dessutom rätt flagga satt sätta blake2-hashsumma och mtime för filen som xattr-värde för var fil den går igenom i filträdet (går i ext4 och BTRFS-filsystem och troligen också i xfs och zfs) och den vägen gör att sökningen nästa gång går väldigt mycket fortare för orörda filer i filträdet och hashar om bara för nya och ändrade filer.

Snapshot av subvolym med BTRFS-filystem tar med alla checksummor som lagras som attribut på filerna i subvolumen som rmlint en gång gått igenom - och tex att med rmlint jämföra snapshot B med snapshot A och göra script som tar bort alla filer i snapshot B som också finns i snapshot A kan gå på bara några minuter fast det är TB-stora instanser och miljoner filer.

Om man har BTRFS som filsystem så kan man också prova med 'bees' som gör en blockmässig deduplikation på hela filsystemet och identifierar ned till 4k-sektornivå även avsnitt i filer som är lika mellan olika filer så att de senare efter deduplikation vid läsning pekar på en och samma sektor eller sektorgrupp - dock kan det få senare läsprestadamässig påverkan då filer med mycket gemensam data med andra filer med deduplicering blir mer eller mindre hårt fragmenterade, vilket sölar ned vid läsning från snurrdisk, kort sagt man byter bättre packning för att spara diskplats mot prestandaförlust vid läsning av filerna!.

ZFS har också funktion där det dedupliceras automatisk vid skrivning till lagring - men kräver 1 GB RAM per TB disk för hash-tabellerna samt dess SHA256-hasning av all data sänker prestandan mer än märkbart - så där behöver man ha en server med muskler och mycket RAM (helst ECC-RAM)

Jag förstår din poäng med MD5 - om det gäller säkerhet likt lösenord. Men för att helt enkelt validera en fil mot en annan för att spara lite utrymme.. som dessutom inte går på AI eller liknande för att även hitta små förändringar, så räcker detta gott och väl då det är mycket snabbare.
Vi snackar inte om en GPU som försöker bruteforcea ett antal miljarder lösenord i sekunden utan en fil som först måste laddas upp - vilket reducerar antalet filer rejält.

https://stackoverflow.com/a/288519/6019661
Ibland räcker det med en simpel lösning

Jag köper argumentet men vidhåller att om kostnaden för tex. en Blake2-hashning inte kostar mycket mer i resurser än en SHA1/md5-hashning så kanske man inte skall välja just md5/SHA1 reflexmässigt och av lathet/vana för att man inte vill/orkar granska alternativ då dessa är faktiskt klassade som 'deprecated' och därmed bör undvikas i nuvarande och framtida design om det finns likvärdiga och bättre alternativ.

Om man ser https://www.blake2.net/ så är blake2b lite snabbare än SHA1 på 64-bits CPU och nära dubbelt snabbare än md5, så stångar man med alternaiven SHA1 och Blake2b mot varandra och det inte finns andra svåröverkommliga infrastrukturella brister för stöd av blake2b så finns det ingen anledning att välja SHA1 idag, och om man ändå måste av olika orsaker - gör det lätt att byta algoritm i framtiden.

Blake2 är en SHA-3 finalist även om den inte vann - men brer mer ut sig som alternativ hash-algoritm i mjukvara hos framförallt opensource-folket av just anledningen att den är faktiskt snabb även i mjukvaru-emulerad form att det slår HW-stödd SHA256 flera gånger om och med hash av mycket bättre kvalitet än md5/SHA1 - ja troligen minst lika bra och bättre än SHA256 i SHA-2 familjen i och med att den var finalist i SHA-3 tävlingen.

Att göra en snabb och bra hash-algoritm samtidigt är en svår konst designmässigt - oftast får man det ena eller det andra...