Re: [9fans] files vs. directories

Re: [9fans] files vs. directories

[Lucio De Re]

> did i hear cloud-backed directory entries?

I'll bite:

If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?

In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganographically encrypted Venti blocks on porno sites?

Oh, I forgot, Al Qaeda is not allowed to download  from sites under the
control of the U.S. Department of Commerce (right department?  hard
to remember).

++L

Re: [9fans] files vs. directories

[Lucio De Re]

> did i hear cloud-backed directory entries?

I'll bite:

If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?

In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganographically encrypted Venti blocks on porno sites?

Oh, I forgot, Al Qaeda is not allowed to download  from sites under the
control of the U.S. Department of Commerce (right department?  hard
to remember).

++L

Re: [9fans] files vs. directories

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 73 bytes --]

My humble apologies for the multiple copies, my fingers slipped.

++L

[-- Attachment #2: Type: message/rfc822, Size: 2904 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@9fans.net
Subject: Re: [9fans] files vs. directories
Date: Fri, 4 Feb 2011 20:31:28 +0200
Message-ID: <ee9ae7e3513885f486adcb41934c06ae@proxima.alt.za>

> did i hear cloud-backed directory entries?

I'll bite:

If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?

In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganographically encrypted Venti blocks on porno sites?

Oh, I forgot, Al Qaeda is not allowed to download  from sites under the
control of the U.S. Department of Commerce (right department?  hard
to remember).

++L

Re: [9fans] files vs. directories

[Enrico Weigelt]

* Lucio De Re <lucio@proxima.alt.za> wrote:

Hi,

> If the cloud were to be a mere repository of (encrypted) Venti blocks,
> wouldn't it be a very useful tool?

Actually, I already had been doing some works in that area.
Not actually venti, but a some bit similar object store,
which supports some kind of distribute gc, etc.
(yet just unfinished code fragments, didnt have the time to
do anything useful yet).

> In fact, how do we know that Al Qaeda are not already storing and
> distributing all their plans for nuking New York on line as
> steganographically encrypted Venti blocks on porno sites?

They don't need to, Langley and DOD have enough datacenters around
the world ...


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] files vs. directories

[Lucio De Re]

> did i hear cloud-backed directory entries?

I'll bite:

If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?

In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganographically encrypted Venti blocks on porno sites?

Oh, I forgot, Al Qaeda is not allowed to download  from sites under the
control of the U.S. Department of Commerce (right department?  hard
to remember).

++L

Re: [9fans] files vs. directories

[Lucio De Re]

> did i hear cloud-backed directory entries?

I'll bite:

If the cloud were to be a mere repository of (encrypted) Venti blocks,
wouldn't it be a very useful tool?

In fact, how do we know that Al Qaeda are not already storing and
distributing all their plans for nuking New York on line as
steganographically encrypted Venti blocks on porno sites?

Oh, I forgot, Al Qaeda is not allowed to download  from sites under the
control of the U.S. Department of Commerce (right department?  hard
to remember).

++L

[9fans] files vs. directories

[dexen deVries]

As this list seems to be open to discussion of strange OS-related ideas, here 
goes my question:

why do we keep distinction between files and directories? Does it provide any 
extra value over model with unified file/directory?

A possible consideration for representation of unified files/directories is a 
three-part file: name (& other meta), byte-stream (==content), ordered list of 
subfiles (== subfiles/subdirectories). In a way, that'd be somewhat similar to 
files with two forks you can see on some OSes. Or, to put it the other way 
around, it's like a directory with extra section for one unnamed byte stream.

Path sematnics stays exactly the same:
read(open("/foo/bar")) returns byte stream related to entry `bar' in (for lack 
of any better word) object  `/foo'.

read(open("/foo")) returns byte stream under entry `foo' in the root object.

readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical 
section of object `/foo'.

The sourece of the idea is a (www) CMS I'm working on which doesn't make such 
distinction, and it somehow makes some sense -- at least as served over HTTP & 
addressed via URIs.


-- 
dexen deVries

[[[↓][→]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90

Re: [9fans] files vs. directories

[erik quanstrom]

> why do we keep distinction between files and directories? Does it provide any
> extra value over model with unified file/directory?

yes.  the advantage is that it's easy to tell the difference
between a file and a directory.  and we have a lot of code
that works with the current model.

what is the extra value of a unified model?

- erik

Re: [9fans] files vs. directories

[dexen deVries]

On Thursday, February 03, 2011 02:05:02 pm erik quanstrom wrote:
> > why do we keep distinction between files and directories? Does it provide
> > any extra value over model with unified file/directory?
> 
> yes.  the advantage is that it's easy to tell the difference
> between a file and a directory.

no comments ;-)


> and we have a lot of code
> that works with the current model.

That was my first objection, too; stuff like acme(1) could become strange: I 
can't imagine how to present mixed bytestream+subfiles/subdirectories in a 
reasonable way. Unless the user left the one of the forks empty, that is...
tar(1) would become confused beyond imagination.

How about 8c(1)? would it be too confusing to issue:
8c foo.c
if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C 
code?

rc(1)? How could `. foo.rc'  handle situation when also `foo.rc/bar.rc/baz.rc' 
exists?


The model seems somewhat sensible in regard to user-oriented documents, 
especially multi-part ones.

`mail/1' could hold body of an email message nr 1, and `mail/1/1' its first 
MIME part.

Perhaps /dev/sd0, /dev/sd0/p0, /dev/sd0/p0/p0 could make some sense in regard 
to drives, partitions etc.?



Perhaps my whole confusion stems from the fact I've never used any record-
oriented filesystem -- otherwise I'd understand pains related to it, as some of 
them would apply in case of my question.


-- 
dexen deVries

[[[↓][→]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90

Re: [9fans] files vs. directories

[erik quanstrom]

> How about 8c(1)? would it be too confusing to issue:
> 8c foo.c
> if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C
> code?
>
> rc(1)? How could `. foo.rc'  handle situation when also `foo.rc/bar.rc/baz.rc'
> exists?

exactly.  this is the same problem one has with arbitrary attributes.

- erik

Re: [9fans] files vs. directories

[roger peppe]

On 3 February 2011 11:45, dexen deVries <dexen.devries@gmail.com> wrote:
> read(open("/foo")) returns byte stream under entry `foo' in the root object.
>
> readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical
> section of object `/foo'.

there's no distinction between readdir and read in plan 9.

Re: [9fans] files vs. directories

[erik quanstrom]

On Thu Feb  3 08:39:20 EST 2011, rogpeppe@gmail.com wrote:
> On 3 February 2011 11:45, dexen deVries <dexen.devries@gmail.com> wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical
> > section of object `/foo'.
>
> there's no distinction between readdir and read in plan 9.

offset tracking is different.

- erik

Re: [9fans] files vs. directories

[dexen deVries]

On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> On 3 February 2011 11:45, dexen deVries <dexen.devries@gmail.com> wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root
> > object.
> > 
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical section of object `/foo'.
> 
> there's no distinction between readdir and read in plan 9.

Forgot about that. Still, you can't chdir() into an inode that doesn't 
indicate being a directory. And the bytestream returned by 
read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for free-
form bytestream.

-- 
dexen deVries

[[[↓][→]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90

Re: [9fans] files vs. directories

[roger peppe]

On 3 February 2011 13:44, dexen deVries <dexen.devries@gmail.com> wrote:
> On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
>> On 3 February 2011 11:45, dexen deVries <dexen.devries@gmail.com> wrote:
>> > read(open("/foo")) returns byte stream under entry `foo' in the root
>> > object.
>> >
>> > readdir("/foo") returns `bar' (and possibly others) -- entries in
>> > hierarchical section of object `/foo'.
>>
>> there's no distinction between readdir and read in plan 9.
>
> Forgot about that. Still, you can't chdir() into an inode that doesn't
> indicate being a directory. And the bytestream returned by
> read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for free-
> form bytestream.

i don't think that helps you.

under plan 9, reading a directory is this:

translate(read(open(dir)))

i don't see how you can make read(open(dir)) return
something different.

oh yes, maintaining the usual semantics for cp becomes tricky.

mkdir z
cp x.c z

do i mean to write x.c to z itself, or to a new file within z?

Re: [9fans] files vs. directories

[dexen deVries]

On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries <dexen.devries@gmail.com> wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries <dexen.devries@gmail.com> wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in the root
> >> > object.
> >> > 
> >> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> >> > hierarchical section of object `/foo'.
> >> 
> >> there's no distinction between readdir and read in plan 9.
> > 
> > Forgot about that. Still, you can't chdir() into an inode that doesn't
> > indicate being a directory. And the bytestream returned by
> > read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for
> > free- form bytestream.
> 
> i don't think that helps you.
> 
> under plan 9, reading a directory is this:
> 
> translate(read(open(dir)))
> 
> i don't see how you can make read(open(dir)) return
> something different.

no contest there. I'd like to have a look at the handling of multiple forks of 
files in other OSes (from userland perspective).

 
> oh yes, maintaining the usual semantics for cp becomes tricky.
> 
> mkdir z
> cp x.c z
> 
> do i mean to write x.c to z itself, or to a new file within z?

I have only linux experience with cp -- and this usage pattern always irked 
me. Theoretically, it's prone to race condition: suppose somebody removes the 
dir `z' right between `mkdir' and `cp'. You `cp x.c z', and end up with `z' 
file. It's unpredictable, unless you're on a single-process OS (yuck).

I'd rather see `cp x.c z' always duplicates bytestream from x.c into z's 
bytestream, whatever `z' happens to be right now. Creating `z' in the process, 
if not present. If you want to have `z/x.c', you'd state that explicitly as 
`cp x.c z/x.c'.

nb., with the current semantics you *could* say `cp x.c z/' to be unambiguous 
you want to create a child of `z', but it seems to be common not to use 
trailing slash unless 100% necessary.


-- 
dexen deVries

[[[↓][→]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90

Re: [9fans] files vs. directories

[smiley]

dexen deVries <dexen.devries@gmail.com> writes:

>> oh yes, maintaining the usual semantics for cp becomes tricky.
>>
>> mkdir z
>> cp x.c z
>>
>> do i mean to write x.c to z itself, or to a new file within z?
>

> nb., with the current semantics you *could* say `cp x.c z/' to be unambiguous
> you want to create a child of `z', but it seems to be common not to use
> trailing slash unless 100% necessary.

dexen hits the nail on the head right there... files and directories
could be contextually distinguished from each other by always specifying
the directory name with a trailing "/".

"foo.c/" means the directory foo.c/.

"foo.c"  means the file ./foo.c

There's no way that I know of to possibly interperet a path ending in
"/" as a file (with the exception of reading raw Dir data, as on Plan
9 or "cat /" on, what was it, Solaris?).

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] files vs. directories

[dexen deVries]

On Thursday 03 of February 2011 19:42:39 smiley@zenzebra.mv.com wrote:
> dexen deVries <dexen.devries@gmail.com> writes:
> >> oh yes, maintaining the usual semantics for cp becomes tricky.
> >>
> >> mkdir z
> >> cp x.c z
> >>
> >> do i mean to write x.c to z itself, or to a new file within z?
> >
> > nb., with the current semantics you *could* say `cp x.c z/' to be
> > unambiguous you want to create a child of `z', but it seems to be common
> > not to use trailing slash unless 100% necessary.
>
> dexen hits the nail on the head right there... files and directories
> could be contextually distinguished from each other by always specifying
> the directory name with a trailing "/".
>
> "foo.c/" means the directory foo.c/.
>
> "foo.c"  means the file ./foo.c
>
> There's no way that I know of to possibly interperet a path ending in
> "/" as a file (with the exception of reading raw Dir data, as on Plan
> 9 or "cat /" on, what was it, Solaris?).


I refuse to be signed under that idea. Really, I hate that idea.

The trailing slash could only be for cp(1)'s interpretation of second argument
-- it literally could mean, ``append the first argument's last component''. To
have it a system-wide policy is overkill. It's only the small optimization
done by cp(1) -- that is, it automagically appends first argument's last
component to the last argument -- that makes this distinction sensible in some
cases.

tl;dr version:
Hell no.

--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] files vs. directories

[Robert Ransom]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Thu, 03 Feb 2011 18:42:39 +0000
smiley@zenzebra.mv.com wrote:

> There's no way that I know of to possibly interperet a path ending in
> "/" as a file (with the exception of reading raw Dir data, as on Plan
> 9 or "cat /" on, what was it, Solaris?).

FreeBSD 8.0 lets you cat the raw data of a directory, and I would
expect the other free BSDs to have that misfeature, too.


Robert Ransom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [9fans] files vs. directories

[erik quanstrom]

> FreeBSD 8.0 lets you cat the raw data of a directory, and I would
> expect the other free BSDs to have that misfeature, too.

i don't see how allowing this is a misfeature.  regardless,
plan 9 allows it.

; sha1sum < /adm/timezone
05d16cd216a58fae746ae36f72c784d10bcc1392

- erik

Re: [9fans] files vs. directories

[Robert Ransom]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Thu, 3 Feb 2011 20:49:17 -0500
erik quanstrom <quanstro@quanstro.net> wrote:

> > FreeBSD 8.0 lets you cat the raw data of a directory, and I would
> > expect the other free BSDs to have that misfeature, too.
> 
> i don't see how allowing this is a misfeature.  regardless,
> plan 9 allows it.
> 
> ; sha1sum < /adm/timezone
> 05d16cd216a58fae746ae36f72c784d10bcc1392

It felt like a misfeature every time I dumped raw directory entries to
my terminal, and I didn't think of a good use like your example.

This feature might be more useful if the directory entries were
presented to clients of the FS in a textual format, but that would
encourage, if not require, far more parsing in the system, and that is
bad both for performance and for security.


Robert Ransom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [9fans] files vs. directories

[Eric Van Hensbergen]

On Feb 3, 2011, at 9:30 PM, Robert Ransom <rransom.8774@gmail.com> wrote:

>> 
>> 
> 
> This feature might be more useful if the directory entries were
> presented to clients of the FS in a textual format, but that would
> encourage, if not require, far more parsing in the system, and that is
> bad both for performance and for security.

Sounds like a good argument for requests to potentially specify response formats (at least in cases where the default is undesirable or sub-optimal for performance reasons)....

  -Eric 

Re: [9fans] files vs. directories

[andrey mirtchovski]

did i hear cloud-backed directory entries?

Re: [9fans] files vs. directories

[erik quanstrom]

> >> >> > > This feature might be more useful if the directory entries
> were > presented to clients of the FS in a textual format, but that
> would > encourage, if not require, far more parsing in the system, and
> that is > bad both for performance and for security.
>
> Sounds like a good argument for requests to potentially specify
> response formats (at least in cases where the default is undesirable
> or sub-optimal for performance reasons)....

wanted: interpreter droid to interpret
the binary language of my moisture evaporators.

- erik

Re: [9fans] files vs. directories

[dexen deVries]

On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries <dexen.devries@gmail.com> wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries <dexen.devries@gmail.com> wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in the root
> >> > object.
> >> > 
> >> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> >> > hierarchical section of object `/foo'.
> >> 
> >> there's no distinction between readdir and read in plan 9.
> > 
> > Forgot about that. Still, you can't chdir() into an inode that doesn't
> > indicate being a directory. And the bytestream returned by
> > read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for
> > free- form bytestream.
> 
> i don't think that helps you.
> 
> under plan 9, reading a directory is this:
> 
> translate(read(open(dir)))
> 
> i don't see how you can make read(open(dir)) return
> something different.
> 
> oh yes, maintaining the usual semantics for cp becomes tricky.
> 
> mkdir z
> cp x.c z
> 
> do i mean to write x.c to z itself, or to a new file within z?

another gotcha would be:

echo aaa > foo
echo bbb > bar

bind -a foo  bar    # or bind -b foo.txt bar.txt

cat foo
any sensible semantics possible?


-- 
dexen deVries

[[[↓][→]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90

Re: [9fans] files vs. directories

[Bakul Shah]

On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries <dexen.devries@gmail.com>  wrote:
>
> why do we keep distinction between files and directories?

David Cheriton's `thoth' operating system didn't keep this
distinction. But every other OS I know of keeps them
separate.  IIRC thoth provided functions for getting the
first child or next sibing given a path name. [Cheriton used
words like father, son, brother -- this was pre-PC!]

> Does it provide any extra value over model with unified file/directory?

They serve functions. A directory is an associative table,
indexed by a string key. A file is an array, indexed by an
integer. But most filesystems do store some attributes with a
file thus breaking this simple model.

One advantage of always storing a directory with a file is
that you can represent file attributes via a directory.  Then
you can have an extensible attributes model.  XML probably
maps well to this model.

Not sure doing so in plan9 makes any sense but you could
build an experimental OS around it! But if you go this path,
do consider providing a few more datatypes in the filesystem
(integers, file-id, strings, ...).  Basically persistent data
types. Or just use an object or relational database as your
filesystem.

There are some uses for cloud based strings :-)

Re: [9fans] files vs. directories

[Eric Van Hensbergen]

On Thu, Feb 3, 2011 at 10:58 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
> On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries <dexen.devries@gmail.com>  wrote:
>>
>> why do we keep distinction between files and directories?
>
> David Cheriton's `thoth' operating system didn't keep this
> distinction. But every other OS I know of keeps them
> separate.  IIRC thoth provided functions for getting the
> first child or next sibing given a path name. [Cheriton used
> words like father, son, brother -- this was pre-PC!]
>
>> Does it provide any extra value over model with unified file/directory?
>
> They serve functions. A directory is an associative table,
> indexed by a string key. A file is an array, indexed by an
> integer. But most filesystems do store some attributes with a
> file thus breaking this simple model.
>
> One advantage of always storing a directory with a file is
> that you can represent file attributes via a directory.  Then
> you can have an extensible attributes model.  XML probably
> maps well to this model.
>
> Not sure doing so in plan9 makes any sense but you could
> build an experimental OS around it! But if you go this path,
> do consider providing a few more datatypes in the filesystem
> (integers, file-id, strings, ...).  Basically persistent data
> types. Or just use an object or relational database as your
> filesystem.
>

I'd tend to agree with this sentiment.  I think, particularly in the
construction of synthetic file hierarchies as interfaces, the tendency
to do what is expected (from a disk file system perspective) often
gets in the way of the sensible interface.  The world has become
considerably richer than collections of byte-stream files, yet we have
no way of notionally representing richer structures in the name space.
 I've actually got some words on this in a position paper I've been
crafting, I'll try to get it out posted to my blog before too long.

        -eric

Re: [9fans] files vs. directories

[smiley]

Eric Van Hensbergen <ericvh@gmail.com> writes:

>> build an experimental OS around it! But if you go this path,
>> do consider providing a few more datatypes in the filesystem
>> (integers, file-id, strings, ...).  Basically persistent data
>> types. Or just use an object or relational database as your
>> filesystem.

IIRC, Reiserfs was aiming to incorporate general database semantics into
the file system design.  /me wonders what ever happened to Hans...

> gets in the way of the sensible interface.  The world has become
> considerably richer than collections of byte-stream files, yet we have
> no way of notionally representing richer structures in the name space.

I occasionally daydream about having naming conventions like:

 $mtpt/timestamp        # application interface node
 $mtpt/timestamp.printf # returns printf strings representing I/O format
 $mtpt/timestamp.usage  # returns human readable help on "timestamp" file

 ...etc.

-- 
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] files vs. directories

[Skip Tavakkolian]

try asking his jail warden.

On Thu, Feb 3, 2011 at 4:24 PM,  <smiley@zenzebra.mv.com> wrote:
>   /me wonders what ever happened to Hans...

Re: [9fans] files vs. directories

[Nick LaForge]

> me wonders what ever happened to Hans...

Is that really necessary?  I'm guessing it was intended as a joke.

Back in the 10th grade I spent a few months running a Reiser4 linux
root.  It was kind of a piece of junk, frequently locking up and
giving inconsistent performance.  C.f.
http://en.wikipedia.org/wiki/Second-system_effect

Nick