[ On Monday, July 14, 2003 at 09:24:06 (-0700), Greywolf wrote: ]
> Subject: Re: funlink() for fun!
>
> GAW> Unlink() cannot, and luckily does not, "just" destroy links to files.
> 
> Actually, that is all it does.

Yes, OK, black is white.  Now you're just being stupid.

> The fact that the data goes away and gets GCd when the link count and the
> reference count (in-core) go to zero is a side effect of the link count and
> the reference count (in-core) going to zero.

True, but the modification of the link count "MUST" be done at the very
same time that the directory entry is modified (just afterwards, but
before the unlink() call returns).

I.e. unlink() does do more than just clear the inode number in the
directory entry, and it does, and "MOST", modify the file itself as
well, and at the same time.

(if you want to talk about side effects then talk about the modification
of the timestamp fields in the file, or other TRUE side effects)

> You're really trying to force the data and the metadata to be equal.

I'm not trying to force the issue because I don't need to.  They are
exactly equivalent.  You cannot have a file without its metadata, though
you can have an empty file, i.e. a file with no content data!

> They are not -- the metadata supercedes the data; the data
> is a child of the metadata.   If the metadata goes away, there is nothing
> to hold onto the data.  This is UNIX by design.

Thank you for confirming that a file is inherently the metadata, and
that the content data is only an adjunct to a true file (if and only if
the file is a regular file which can contain data, and if and only if
there is any content in the file).

I.e. don't forget other "empty" files, such as devices and FIFOs.  They
are very much "files", but they have no associated data storage blocks.

> GAW>  However directory entries
> GAW> (names) are just pointers to the real files.
> 
> Correction:  They are pointers to metadata (inodes).

No, not a "correction" -- real files _are_ the "inodes".  Period.  The
data they contain, or the lack thereof, is irrelevant here.

File _NAMES_ are the pointers to the real files.  Please try to keep
this most important distinction separate in your mind.


> You are proposing a major rewrite to in-core filesystem semantics.

No, I am not.  You have clearly not paid any attention whatsoever to the
core of this discussion.  funlink() as I've described it can in fact be
"trivially" implemented totally transparently to any existing kernel
function or data structure (in-core or on-disk).  Obviously such a
"trivial" implementation would not be the most efficient or optimized
implementation, but it would work just fine without changing any
existing filesystem semantics or syntax.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>