Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!agate!dpassage From: dpassage@soda.berkeley.edu (David G. Paschich) Newsgroups: comp.unix.wizards Subject: Re: file attributes Message-ID: Date: 20 Jun 91 08:11:00 GMT References: <1743@sranha.sra.co.jp> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: UC Berkeley's Open Computing Facility Lines: 31 In-Reply-To: erik@sra.co.jp's message of 20 Jun 91 00: 14:41 GMT 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] So we need a new system call, say, mopen(), which opens a file that contains attributes such as the application name. This would allow old programs to continue to use open() to access the data itself. The stat() call would also be left unchanged. The size of the attributes file could be determined by calling fstat() on the file descriptor returned by mopen(). 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. -- David G. Paschich Open Computing Facility UC Berkeley dpassage@ocf.berkeley.edu "Can Spam increase sexual potency? `No!' say scientists!" -- Trygve Lode