*BSD News Article 63874


Return to BSD News archive

Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!daily-planet.execpc.com!news.sol.net!news.inc.net!trellis.wwnet.com!nntp.coast.net!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netcom.com!kalessin
From: Adam Megacz <kalessin@netcom.com>
Subject: Re: Ideal filesystem
Content-Type: text/plain; charset=us-ascii
Message-ID: <3150DCF5.FB40BBD@netcom.com>
Sender: kalessin@netcom22.netcom.com
Content-Transfer-Encoding: 7bit
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <4gejrb$ogj@floyd.sw.oz.au> <4gilab$97u@park.uvsc.edu>
		<4giqu8$aqk@park.uvsc.edu> <4gira2$a9d@park.uvsc.edu>
		<hpa.31321eee.I.use.Linux@freya.yggdrasil.com>
		<4h7t5i$qoh@park.uvsc.edu> <DnoqB4.2sy@pe1chl.ampr.org>
		<glDH59i00YUvFFjspX@andrew.cmu. <4hptj4$cf4@cville-srv.wam.umd.edu>
		<3140C968.20699696@netcom.com> <4ia7im$i4m@usenet.srv.cis.pitt.edu>
		<314A470D.CCE53F0@netcom.com> <yw03f73fn8v.fsf@laurel.trs.ntc.nokia.com>
Mime-Version: 1.0
Date: Thu, 21 Mar 1996 04:37:09 GMT
X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i486)
Lines: 103
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:19684 comp.unix.bsd.freebsd.misc:15694

> Often these have been available with ident command.
> 
> >   - Icons for Xfilemanager, Xfm, etc...
> 
> Yes, seems these are wanted. However, perhaps we had better design a
> binary format which can include bitmaps, comments, etc. Much like
> Windoze has, as extra sections with well known names in the file.
Yes, but existing file formats (word6, tar, gzip, etc) don't have space
for an icon in their formats.

> >   - MOST OF ALL, FILE TYPE! The standard UNIX mechanism for determining
> > file type is *almost* as crappy as WinDoze's (filename extensions). This
> > is one of the few areas where the Mac & OS/2 kick Linux's butt.
> 
> file command does this to some degree. Not as well, but anyway.
                                         ^^^^^^^^^^^
Amen.


> This has the practical problem, that how does the type get into the
> file? Would you add it by hand separately to each file or do you think
> programs would be modified soon to do it well enough to be of use?
Over time, more and more apps would add the information when the file
was written (i.e., like OS/2 & Mac). For now, there could be a program
that goes thru the whole filesystem, runs "file" on each file, and
assigns a type that way. This program could be run periodically (once a
month) until a significant number of apps supported FileType EA's.


> >   - Short description of what a file does - this is a MAJOR help for
> > novice sysadmins. Also provides a more convenient place to store
> > "whatis" information.
> 
> README file is often more useful.
And often hard to find. Lots of sysadmins just delete these, or put them
in some arcane location other than /usr/doc (which is usually hard to
sort thru, anyways.) If the README is stuck to the file you CAN'T lose
it.

> Besides, I doubt a novice finds anything which is not shown by ls. A
> real novice has enough trouble to understand files and directories,
> let alone extended attributes.
UNIX wasn't made for novices. Besides, you can just tell them to type

   purpose <filename>

to print out the "purpose" EA of a file.


> > > the point is resources/EAs are poorly defined, and not designed at all.
> > NO - they provide FLEXIBILITY for the future.

 
> I see problems. What all kind of information would end up as EAs?
Anything you like!

> Icons, icon positions and other user interface specific information,
> various versioning system information, operating system specific
> information, etc?
Yep.

> How to cope with foreign information?
Foriegn languages? I dunno. I only speak English and Spanish, but I'm
sure there's a workaround for other character sets like Russian.

> What parts of
> this information would you like to have copied with cp?
All of it.

>  What should
> tar, cpio etc. store with the file?
All of the EA's. Tar's file format already has space reserved for EA's.

> What about NFS and other network
> file system users? Should some parts of this information be privileged
> and other publicly available?
The file permissions would apply to EA's as well. It's an all-or-nothing
deal.


> Naming standards to avoid attribute name
> space problems?
Yep.

> Information format? Big endian, little endian, etc.
Probably whatever endian is used by other UNIX file formats (tar, xbm,
xpm, gzip, etc)


> Perhaps what you really want is a WEB like filesystem where you have
> no files and directories. Only pages with links. Some links start up
> program binaries, some source code editors, etc. I have a feeling this
> is what Netscape is planning.

Nah. Actually I'm considering a previous posting about eliminating the
difference between files and directories - and making all files
directories that can be read as streams. This kinda fits the UNIX
mindset better.

-- 
Adam Megacz <kalessin@netcom.com>
Website ftp://ftp.netcom.com/pub/ka/kalessin/adam.html
Linux - OS/2