Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!axion!uzi-9mm.fulcrum.bt.co.uk!cat.fulcrum.bt.co.uk!cnix!klaus From: klaus@cnix.uucp (klaus u schallhorn) Newsgroups: comp.unix.wizards Subject: Re: file attributes Message-ID: <1991Jun20.184034.18705@cnix.uucp> Date: 20 Jun 91 18:40:34 GMT References: <1743@sranha.sra.co.jp> Organization: pionier publications Lines: 33 In article dpassage@soda.berkeley.edu (David G. Paschich) writes: >In article <1743@sranha.sra.co.jp> erik@sra.co.jp, > (Erik M. van der Poel) writes: > > It is almost possible to create a Mac-like interface on Unix, but this > involves incredibly convoluted methods such as keying off of the name > of the file, or checking the contents of the file for certain known > properties of an application's files. Again, there are no standards in > this area. Unix needs to be extended to allow attaching all sorts of > attributes to files. The inode is not extensible. > >[stuff removed by dgp] > >I think a better solution than extending the Unix file system in this >way would be to create a file, named say .desktop (or something more >clever to avoid lawsuits :) which would contain this information, and >then writing some library calls which would maintain this information >and make it available to programs. This also makes the code a lot >more portable since it doesn't rely on the particular Unix providing >the facilities you describe. > What's wrong with file(1) and a proper /etc/magic table? mine is 111 lines and recognises all the file types I care about. As an aside, a system's usefulness will be highly impaired by forcing users to use program x with files of type y. That may be permissible on MacChickenBurger Boxes but not on my systems. klaus schallhorn -- George Orwell was an Optimist