Subject: Re: funlink() for fun!
To: Greywolf <>
From: Greg A. Woods <>
List: tech-kern
Date: 07/14/2003 17:43:30
[ On Monday, July 14, 2003 at 11:20:59 (-0700), Greywolf wrote: ]
> Subject: Re: funlink() for fun!
> For your definition that file == inode, fine.

Thank you, finally.  FYI you'll find essentially the same definition in
all the serious books about Unix internals.

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

Perhaps you've never done anything even remotely like "find -x
/mountpoint -inum 12345 -print".  You can't have.  Otherwise you'd
probably understand at least some of what I'm talking about.  (Yes,
that's meant entirely as sarcasm.)

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

It's not impossible, or even necessarily impractical given the lack of
better alternatives for safe and secure programming in some situtations,
so, it is still something to think about.

I do think der Mouse's O_NOACCESS flag (and perhaps my O_MKDIR flag as
well), along with the extra fchdir() and fstat() calls they require, is
better than funlink(2) since they have a better chance of completeing
successfully, even in the normal case, and a potentially much better
chance of giving useful diagnostics in the failure case and doing so in
a timely fashion.  However until you understand what I'm talking about
you can't even begin to sanely discuss funlink(2) or its alternatives on
the same level playing field.

I.e. unless and until you can understand funlink(2) as I've described
it, together with all its implications and limitations and possible
optimisations, you cannot possibly even begin to make any fair or
reasonable assessment of any of the alternatives to this most obvious
solution to the underlying problem (i.e. the problem which prompted me
to open the discussion in the first place).

						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>