Re: Random idea:

["chen" <chen@slangsoft.com>]

> 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...