[TYPO3-core] RFC: Make image hash names longer to avoid collisions

Martin Kutschker Martin.Kutschker at n0spam-blackbox.net
Wed May 16 17:31:42 CEST 2007

Ernesto Baschny [cron IT] schrieb:
> Karsten Dambekalns wrote: on 16.05.2007 14:55:
>> Type: bugfix, somewhat
>> Branches: all 4.x if you like
>> We recently saw some cases of wrong images being displayed. After
>> investigating we concluded that the only possible explanation could be a
>> name collision, because two different images got the same short md5 hash
>> as generated filename.
>> This possible problem has been discussed back in 2004, btw:
>> http://lists.netfielders.de/pipermail/typo3-dev/2004-July/004597.html
>> The attached patch fixes the issue for me, the length of the hash in
>> then configurable via TYPO3_CONF_VARS, default stays with 10 chars to
>> make sure nothing changes. For trunk we could make this 32, I'd say.
>> Names will then have longer md5 names, massively reducing the risk of
>> name collisions.
> I guess if you had this problem with resizes created by imagemagick, we
> will end up having the same problem in every place we currently use
> "short" md5's. There might be places where the risk is lower (less
> entries), but images are certainly not the only place where there might
> be massive amounts of variants. So maybe we could switch to 32-chars on
> more than just this place? I can think of: cHash, Imagemagick output,
> GIFBUILDER output, maybe others. And also be aware of the places where
> this has is written to the DB, the field might be too small.

I never understood the logic of using truncated md5 hashes and argued 
before to use only the real hashes. Certainly the "beauty" of a generated 
filename cannot be a reason, right?


More information about the TYPO3-team-core mailing list