Eric Schrock wrote:
> On Mon, Jun 25, 2012 at 11:19 AM, wrote:
> >
> >
> > In the very beginning, mkdir(1) was a set-uid application; it used
> > "mknod" to make a directory and then created a link from
> >newdir to newdir/.
> > and from
> >"." to newdir/..
> >
>
> Interesting, g
On Mon, Jun 25, 2012 at 11:19 AM, wrote:
>
>
> In the very beginning, mkdir(1) was a set-uid application; it used
> "mknod" to make a directory and then created a link from
>newdir to newdir/.
> and from
>"." to newdir/..
>
Interesting, guess you learn something new every day :-)
Eric Schrock wrote:
> The decision to not support link(2) of directories was very deliberate - it
> is an abomination that never should have been allowed in the first place.
> My guess is that the behavior of unlink(2) on directories is a direct
> side-effect of that (if link isn't supported, the
>The decision to not support link(2) of directories was very deliberate - it
>is an abomination that never should have been allowed in the first place.
>My guess is that the behavior of unlink(2) on directories is a direct
>side-effect of that (if link isn't supported, then why support unlink?).
>
The decision to not support link(2) of directories was very deliberate - it
is an abomination that never should have been allowed in the first place.
My guess is that the behavior of unlink(2) on directories is a direct
side-effect of that (if link isn't supported, then why support unlink?).
Also w
I don't know the precise history, but I think its a mistake to permit direct
link() or unlink() of directories. I do note that on BSD (MacOS at least)
unlink returns EPERM if the executing user is not superuser. I do see that the
man page for unlink() says this on illumos:
