Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> > GAW> Unlink() cannot, and luckily does not, "just" destroy links to files.
GAW> >
GAW> > Actually, that is all it does.
GAW>
GAW> Yes, OK, black is white.  Now you're just being stupid.

Coming from you, I'm going to take that as a compliment.

GAW> > The fact that the data goes away and gets GCd when the link count and the
GAW> > reference count (in-core) go to zero is a side effect of the link count and
GAW> > the reference count (in-core) going to zero.
GAW>
GAW> True, but the modification of the link count "MUST" be done at the very
GAW> same time that the directory entry is modified (just afterwards, but
GAW> before the unlink() call returns).

And this relates to the price of beer in Germany just how, again?

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

Ah.  I see what you're getting at.  You're trying to tell me that the file
is the inode, and that data is connected with said inode is a side effect.
I get it.

(Not.)

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

Yes, those are there, too.

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

You cannot have a file's *data* without its metadata.  You can have metadata
that corresponds to zero allocation to data (think "device").

GAW> > They are not -- the metadata supercedes the data; the data
GAW> > is a child of the metadata.   If the metadata goes away, there is nothing
GAW> > to hold onto the data.  This is UNIX by design.
GAW>
GAW> Thank you for confirming that a file is inherently the metadata, and
GAW> that the content data is only an adjunct to a true file (if and only if
GAW> the file is a regular file which can contain data, and if and only if
GAW> there is any content in the file).

I don't think I've quite argued otherwise, other than I have missed the
Woods definition of a "file".

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

Thank you for confirming that a file's data is connected to an inode, but
is not an inode.

GAW> > GAW>  However directory entries
GAW> > GAW> (names) are just pointers to the real files.
GAW> >
GAW> > Correction:  They are pointers to metadata (inodes).
GAW>
GAW> No, not a "correction" -- real files _are_ the "inodes".  Period.  The
GAW> data they contain, or the lack thereof, is irrelevant here.

Obviously it's not irrelevant here or you wouldn't be getting so many
people out here telling you why funlink() wouldn't work given the current
API without a major bloody rewrite.

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

For your definition that file == inode, fine.

name -> inode.  Great.  Fine.  Whatever.  N:1
inode -> name.  1:N.  Pain in the patella.

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

Depending on how you want to do it, sure, fine, whatever.

As the semantics exist right now, it is not a practical idea.

				--*greywolf;
--
NetBSD: The free OS with a money back guarantee!