Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!solace!nntp.uio.no!news.cais.net!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: Sat, 20 Apr 1996 14:10:11 -0700
Organization: Me
Lines: 88
Message-ID: <317952B3.4350D3CB@lambert.org>
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4jpjb6$77c@park.uvsc.edu> <jlemonDpEw1v.4Ez@netcom.com> <4kfoqd$dgs@coyote.Artisoft.COM> <DpvCB7.xn@midway.uchicago.edu> <199604161704.SAA02116@kythera.demon.co.uk>
<31740EB4.20617DC8@lambert.org> <199604181734.SAA04797@kythera.demon.co.uk> <3176BCFC.154575ED@lambert.org> <199604200114.CAA09041@kythera.demon.co.uk>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21975 comp.unix.bsd.freebsd.misc:17857
Ray Auchterlounie wrote:
] Yes, in applications that understand it. For DOS applications running
] in an emulator (for example) it would be useful if file attributes
] could be (at least) read from a file.
I have to ask "why?" here. For DOS applications running in an
emulator, you're not going to be able to manipulate UNIX text
files satisfactorily, let along things like icons or inherited
rights attributes.
] >Much of what would constitute the space of "useful EA's" is a
] >collection of *state information*, not a collection of data
] >streams. State information that is sometimes the result of
] >file system events and is *read only* to the user.
]
] It could still be read as a file - "cat /proc/net/route".
] I think /proc is useful - others probably dont.
People love plan nine because they can say "just do this"
or "just do that". It's really the word "just" they are in
love with, not the actual implementation.
I agree that /proc FS's are useful. I'll even agree that
thay are underutilized... but "/proc/net/route" is simply
abuse of an existing paradigm.
] This was exactly what I was trying to suggest in my first post in this
] thread - obviously not very clearly. We are in fact agreed.
]
] If you implement the FS "properly" but have the option of a
] file-as-directory view/translation/loopback/whatever, then almost all
] of the pro file-as-directory arguments go away.
Yes. My point in that particular subthread was that there was
no overriding benefit to be derived from a file-as-directory
implementation that you couldn't get in nearly any other
situation. That's why I wasted the time to implement it for
executable files in a FreeBSD UFS (I used my IS_UNICODE attribute
for it) -- to show that it was a trivial idea.
] [...]
] >Oh well. Your choice to use NetWare in a mixed environment.
] [...]
] >If you change to a non-mixed environment of one kind or the
] >other, you won't have these problems.
]
] ??? This was a "mixed" environment of PCs running DOS/Windoze and a
] Fileserver (also PC) running Netware, how do we make it less mixed ?
NetWare works with NetWare. It didn't work with UNIX (or with
the UNIX command tar) because you attempted to mix paradigms.
This is almost always a bad idea.
Novell doesn't have an SDMS user agent for UNIX systems... even
their own UnixWare never had one (the person whom our NetWare
for UNIX group inside Novell was supposed to get for the
implementation was constantly being resceduled for higher
priority work on Native NetWare and only came up to Sandy from
Provo once or twice).
] We could have had access to a DAT drive shared between research
] groups (for a fraction of the cost), but this was on a unix box
] elsewhere - so the tools that could talk to it (eg. tar) couldn't
] backup attributes. So we bought our own... (with same problem).
Here is your mistake: you *thought* you had access to a DAT
this way, but you didn't actually have the access you thought
you did.
If you then bought your own DAT, hooked it to a NetWare box, and
it failed as well, all I can say is talk to whoever wrote the
SDMS agent for the DAT and make them fix it. Failures in a
homogenous NetWare environment are a hell of a lot rarer than
those in homogenous Microsoft OS or UNIX environments. Internal
consistence is one thing Novell does *damn* well.
You *are* using an SDMS agent on the machine with the DAT, right?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.