aliensrcooluk at yahoo.co.uk wrote: Using the extension name *and* something else is just as bad (worse?) IMO as using the extension name itself. You don't call yourself andrew.human.male so why should a file's name have to carry all of that information? E.g., TIFF's can be stored in Moto or Intel byte order (big/little Endian). Why aren't there .TIFFi and .TIFFm extensions to differentiate between the two (ans: because TIFF decoders are smart enough to Do The Right Thing) Adding *superfluous* IN-BAND data just to identify the file type is also A Bad Idea (IMO) as the information is redundant (if the file extension *clearly* is doing it's job, then why do we need to RESTATE all of this information within the file?). And, it requires applications and utilities (e.g., listing a directory's contents) to *open* each file to determine what the file is -- instead of stat()-ing it (somehow). Sure! But, then you are conceding that the information contained in the file extension is "worthless" :> I have the philosophy that code should protect itself be able to trust the data sources that it interacts with. E.g., if someone wants to pass a *humongus* image file to my image decoder, I should correctly decode/display it (subject to the resource constraints imposed on my by the OS at this instant) -- even if it is a 500MB image of a large black rectangle! (or, "white noise") This means you have to scan the file to verify that it is "that type". Great if your application is the only one looking at those files and you can afford the time to scan them to verify this. But, not an efficient way of handling "file typeS" in general.

Hi, Andrew B said: That's how the xfm file manager does it. There's a (user maintainable) file of magic data, for example xfm knows gifs start "GIF87a" or "GIF89a" TIFFS start 0x4d4d or 0x4949. So it can ignore extensions if it needs to. -- Cheers, Stan Barr stanb at dial.pipex.com The future was never like this!