> This of course seems like a nice idea, but it has some pitfalls: > - file systems would need to generate this information "on the fly"
Actually my idea was that the file system would *keep* the mime type with the rest of the information (permissions and so) and use it. The question is ofcourse how would the data be generated. I see couple of ways: The program creating the file can record the file type when creating it. There can be a default file type umask It can be controled from command line by chtype [file] [type] > (you should expect other OS's to manipulate data, so you cannot > rely on stored type information - you would need to verify this > at least during the startup of the translator, so you better > should do it on the fly - if at all) I don't think it should be verified. if the type is wrong, the program trying to use it will complain nicely > - types would need to be determined from the data alone so > that foo.txt would be clearly identifiable as X-Bitmap if > foo.txt's data is a valid X-Bitmap - but what are you going > to do about foo.txt.gz? After all - you are still interested > in the X-Bitmap and you probably regard compression as something > that should be somewhat transparent, don't you. no it can be identified as gzip compressed file. > A long time ago one of the HURD developers rejected the idea > and I am increasingly of the opinion that he was right. > (If I remember right it was related to resource forks present > on HFS file systems as used by Apple PC's.) I knew I can't be too original :-) [historical overview cut] What I'm suggesting is to save the info in the file system itself. I think that because of the way hurd implements file systems, it may work nicely. Thanks for the info! Chen Shapira. and miles to go before I sleep...