Reverting mknod

[Michael Ambrus]

Thank you guys - I much appreciated the answers (including the history
lesson :) ).

I think Shap figured out why I'm asking and managed to give me exactly
what I needed.

The reasons I'm asking is that unlink is the only function of the
possible ones that's part of the syscalls and seems therefore to be
the lowest level _any_  un-bind operation would have to use
eventually.

I.e. transaction management and other consistency related operations
would have to be higher level (i.e. rmdir() or remove() by that
reasoning). Please correct me if I'm wrong.

Best
/Michael

On 4/23/07, Jonathan S. Shapiro <shap@eros-os.com> wrote:
> Historically, unlink() handled ALL entries (even directories). It's job
> is to unbind any single directory entry, decrementing the target
> reference count if appropriate. rmdir() was added later when it was
> noticed that a transaction barrier on the file system was required. At
> that point, directory unbind became a special case.
>
> So the answer to the original question is: unlink() is responsible for
> un-binding anything that is not a directory
>
> On Mon, 2007-04-23 at 14:15 +0100, Dave Korn wrote:
> > On 23 April 2007 14:06, Michael Ambrus wrote:
> >
> > > What does the standard say should be the opposite of mknod?
> > >
> > > Or in other words: how do I remove a file of any type?
> > >
> > > I thought it would be unlink, but I'm not certain and the info at
> > > opengroup doesn't seem to support it.
> >
> >   It (the documentation) seems to imply that it (unlink) does (handle special
> > files) to me; the only thing it (docs again) says it (unlink again) won't
> > accept is a directory, but it (unlink) doesn't discriminate between special
> > and ordinary files.  The file created by mknod may have some flag bits set,
> > but it's (the file) basically a hardlink/inode on a disk, just like any other.
> >
> > [  This post has been edited to clarify a profusion of pronouns with uncertain
> > referents!  ]
> >
> >
> >     cheers,
> >       DaveK
>
>