Re: why not remove AF_LOCAL sockets on last close?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
>>> sockets from the filesystem on last close?

Well, I wouldn't expect it to be easy; it means that every AF_LOCAL
socket needs to keep track of its <directory,name> pair.  This leaves
open the question of what to do if it has multiple links when whatever
point you consider "last close" arrives.

For most purposes it would probably be good enough to do something like
"if the originally-bound name in its original directory still refers to
the same socket, unlink it; ignore other issues".

>> If you want to do that, wouldn't it be easier to just go the Linux
>> route and move them into a separate (virtual) namespace completely?

Easier?  Maybe.  But you'd lose the (currently almost free) leveraging
of the other attributes of overloading the filesystem namespace, such
as permissions checking.

> Linux does that?  I ran this test program on a Linux system and got a
> socket in the filesystem and the same results.

I haven't tried it myself, but I've been told that Linux does that
*sometimes* - specifically, if the pathname begins with a NUL but the
address length indicates that there's more pathname following it.

I don't know whether there's anything like a hierarchical filesystem
namespace there or whether they're just opaque octet-string blobs.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B