> On 24 Jun 1998 21:40:07 -0000, "Stig HackVan" <stig@hackvan.com> said:
>
> > I'd very much like to see something like the simple database functionality
> > of the BeOS filesystem. I'm on a severe typing diet, however, so I'm
> > unlikely to be able to do more than consult on the feature set and
> > implementation.
>
> > On BeOS, all files can have an arbitrary list of name/value pairs associated
> > with them. These attributes can be globally indexed or not.
>
> Fine for a new operating system, but remember that Linux is
> Unix/POSIX, not BeOS compatible. That means that every single program
> which moves, copies or archives files is expected to be just a
> standard byte stream.
>
> We already have solutions to most of the file attribute problems; they
> are user-space rather than kernel-space solutions. Given that the
> general rule is to place something into the kernel only if there is a
> convincing argument why it should not be done in user space, I can't
> see that we want to put such a database into the kernel. It would be
> nice, sure, but do we really want to fork a branch in the Unix spec
> and have to maintain our own completely incompatible versions of
> everything from cp to tar, not to mention the impact on third-party
> archive tools?
I still think compatibility with other operating system might be the
argument why to introduce such features into Linux. Or how does one
access such data for example on a BEOS, HPFS or NTFS partition? How
about data like access lists, security labels and maybe more in the
future, everything data which really should be associated to a file
such that it cannot be lost and with access control by the kernel?
Such features are needed and we somehow have to deal with them. I
wholeheartly agree with Stefen's concern about having incompatible
versions of everything, but I think we can work around that.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu