checksum af fil - eller anden idendifikation

Gem en MD5 eller SHA1 i din database. Så længe filen er identisk med den gemte, vil du med 100% sikkerhed genkende den.

Vær dog opmærksom på at du ikke kan genkende en fil hvis der eks. ændres i dets tag.

altså.. en MD5 laver en kryptering af filnavnet ikk?

Nej - meningen er at du skal bruge MD5 til at lave en hash (MD5 er ikke kryptering!) af filens indhold. Det burde du kunne gøre med noget i stil med

<? $hash=md5(file_get_contents($filnavn)); ?>

Måske sådan her:
function checksum($file)
{
  return sprintf("%u", crc32(file_get_contents($file)));
}

hvad er en hash?

er ikke lige helt med her

En hash værdi er en streng bestående af en masse underlige tegn, genereret ud fra en given streng, og hash værdien kan ikke laves om til original strengen igen.

men vil det ikke tage mange resourcer hvis man bruger en hash som id i en database?

En hash er meget kort - for MD5 bliver den gemt som 32 tegn. Ved CRC32 skal du kun bruge 8.

Det vil dog tage en del resourcer at beregne den, hvilket er grunden til du nok bør bruge CRC32 som hmortensen foreslår - den er ikke så kompliceret at beregne, så der bruges ikke så mange resourcer.

hvordan kan jeg så beregne en fil fra et andet drev?

eks.
echo checksum('d:\dir\fil.mp3');

No such file or directory

At udregne en crc32 for over 1000 filer vil måske ikke gå helt vildt hurtigt, og chancen for at flere filer vil have samme checksum er vel "rimelig" stor?

Måske skulle man lave indifikation på en lidt anden måde?

Jeg ved ikke om det evt. ville gå hurtigere hvis havde 2 felter som var primary keys? Altså en med crc32 af filnavnet (ikke hele filen) og det andet felt vil være stien til filen som integer. Så der findes en anden table med id og path? Hvis man kan følge mig? Eller er det en endnu bedre metode? :)

prøver lige igen.. hehe

Jeg ved ikke om det evt. ville gå hurtigere hvis man havde 2 felter med primary keys? Altså et med crc32 af filnavnet (ikke hele filen) og det andet ville være stien til filen som integer (id på stien). Ved siden af findes så en table med id og sti? Hvis man kan følge mig? Men her kan man så ikke ændre sti til filer uden at det vil få konsekvenser

Eller er der en endnu bedre metode? :)

eller hvad med crc32 af filnavn i et felt og crc32 af indhold af filen? :)

jeg ved ikke hvor mange resourcer det til tage?

Chancen for at der er kollision mellem 2 forskellige filer er 1 til 2^32. Hvis du samtidigt gemmer filstørrelse, er chancen endnu mindre.

Hvis du laver en CRC32 af filnavnet, ender du med samme problem - du har ingen mulighed for at finde en omdøbt fil.

Tanken er at du ved upload udregner CRC32 for filen, og gemmer den i databasen. På den måde skal du kun checke EN gang.

En yderligere fordel ved at bruge CRC32 frem for noget andet, er at du kan omdanne den til et tal der kan være i en INT kolonne. Det gør søgning hurtigere hvis du har indekseret kolonnen.

Eksempel på en brugbar tabelstruktur:

filcrc (P)
filsize (P)
filsti
+de oplysninger du ellers vil gemme (kunstner, titel, etc.)

For at beregne CRC32 på en eksisterende fil, skal du sætte dit filnavn ind i file_get_contents(). Vær opmærksom på du muligvis skal øge den mængde hukommelse PHP må bruge.

jeg tror lidt at det med at beregne crc32 for hele filen vil bruge for mange resourcer...

ville det ikke være lige så godt at lave crc32 af filnavnet og have filstørrelsen som primary key?

- for hvis du ændrer filnavet til både crc32 for filnavn og hele filen alligevel ændrer sig.. det samme for filstørrelsen

jeg går ud fra at jeg ikke ændrer noget i filen som ID3 eller filnavnet :)

til=vil
ændrer=ændre

er vist ved at være træt.. hehe

CRC'en ændrer sig ikke hvis du omdøber en fil. Den ændrer sig kun hvis du ændrer selve filens indhold, såsom ID3 tag. Derfor er det mere fleksibelt at beregne på filens indhold.

Desuden kan jeg melde om at min bærbare er ca. 2 sekunder om at beregne CRC32 for en 5MB stor fil, og da det kun skal gøres en gang...

i øvrigt tager det ca. lige så lang tid at beregne MD5 for samme fil ;)

kan jeg godt have alle udregningner fra crc32 i en INT(10)?

når jeg prøver at browse filer på et andet drev på serveren får jeg fejl?

checksum('e:\dir\fil.mp3');

No such file or directory

Alternativ til crc32 af hele filens indhold, kunne man så ikke gøre noget i stil med det her? Her ville man vel også få mindst chance for at 2 filer kommer til at virke synkrone

file_size
crc32(file_name)
path_id

Som sagt så mange gange før - hvis du bruger CRC32 til filnavn mister du al mulighed for omdøbning, og muligvis også flytning (afhængig af om du også tager stien med).

Du skal have EKSTREMT mange filer før det reelt kan betale sig kun at operere på filnavn, da en CRC32 på 5MB som nævnt kun tager et sekund eller to.

Endelig er der jo heller ikke megen ide i at gøre det med mindre du gemmer filnavnet andetsteds, da du jo ikke har mulighed for at vide hvad der er hvad - en CRC32 kan ikke bruges til at genskabe det originale indhold.

jamen jeg har lige observeret noget ret interessant... der må åbenbart være "reserveret" 255 tegn i hvert felt i ID3 :)

så længe man ikke sletter et helt felt eller skriver i et tomt ændrer filstørrelsen sig ikke

Nu kan man vel bare nøjes med at bruge filstørrelsen id, for man ændrer vel heller ikke filstørrelsen ved at ændre filnavnet?

Skal lige siges at det KUN er ved ID3v2, og at filstørrelsen heller ikke ændrer sig hvis man helt sletter felter eller skriver i tomme felter :)

Men jeg bruger også kun ID3v2...

Du kan godt have to filer der er lige store, uden at de er identiske. Derfor holder den ide ikke.

Mht. til ID3, så vil dine filer ændre sig uanset. Filstørrelsen ændrer sig ikke ved ID3v1 (så længe der er et tag defineret), men den gør den nu ved ID3v2 (husk på vi snakker ned på byte niveau), da tagget ellers ike vil kunne blive læst ordentligt (grundet formatets definition).

jeg synes altså heller ikke at filstørrelsen ændrer sig i ID3v2.. har selv lige prøvet at have helt tomme felter og dernest alle udfyldte, uden det ændrer sig (tæller bytes)

jeg ville nu heller ikke kun have id på filstørrelsen, men en delt primær nøgle på filstørrelse og crc32 på filnavnet

Det eneste ID3v2 format der kan gøre det, er v2.4, og selv der kræver det at din tagger er sat op til at kunne gøre det (det er muligt at lave padding i v2.4, men ikke i v2.2. eller v2.3).

Det er bedre med den delte nøgle, men igen, dubletter. Er det virkelig det værd bare for at spare nogle få minutter når du lave din indledende database?

kunne en crc32 så være i en int(10) eller skal man op i en bigint?

Det burde kunne være i en int(11), da der er tale om 32-bit.

int(11) ?

2^32 = 4294967296

du kan lige lave et svar samtidig :)

Den bliver returneret som en unsigned integer, så smid heller 11 på for en sikkerheds skyld. Det er desuden det PMA bruger som standard til en INT.

Og her er svaret :)

PMA?

PMA=PHPMyAdmin. Det værktøj mange bruger til at administrere MySQL databaser.

ja ok.. kendte ikke lige til den forkortelse

men tak for hjælpen :)