Re: FS: hardlinks on directories

[Jesse Pollard <jesse@cats-chateau.net>]

On Monday 04 August 2003 10:57, Richard B. Johnson wrote:
> On Mon, 4 Aug 2003, Stephan von Krawczynski wrote:
> > On Mon, 4 Aug 2003 09:33:44 -0500
> >
> > Jesse Pollard <jesse@cats-chateau.net> wrote:
> > > Find for one. Any application that must scan the tree in a search. Any
> > > application that must backup every file for another (I know, dump
> > > bypasses the filesystem to make backups, tar doesn't).
> >
> > All that can handle symlinks already have the same problem nowadays.
> > Where is the difference? And yet again: it is no _must_ for the feature
> > to use it for creating complete loops inside your fs.
> > You _can_ as well dd if=/dev/zero of=/dev/hda, but of course you
> > shouldn't. Have you therefore deleted dd from your bin ?
> >
> > > It introduces too many unique problems to be easily handled. That is
> > > why symbolic links actually work. Symbolic links are not hard links,
> > > therefore they are not processed as part of the tree. and do not cause
> > > loops.
> >
> > tar --dereference loops on symlinks _today_, to name an example.
> > All you have to do is to provide a way to find out if a directory is a
> > hardlink, nothing more. And that should be easy.
>
> [SNIPPED...]
>
> Reading Denis Howe's  Free Online Dictionary of Computing;
> http://burks.bton.ac.uk/burks/foldoc/55/51.html, we see that
> the chief reason for no directory hard-links is that `rm`
> and `rmdir` won't allow you to delete them. There is no
> POSIX requirement for eliminating them, and it is possible
> "Some systems provide link and unlink commands which give
> direct access to the system calls of the same name, for
> which no such restrictions apply."
>
> Perhaps Linux does support hard-links to directories?
>
> mkdir("foo", 0644)                      = 0
> link("foo", "bar")                      = -1 EPERM (Operation not
> permitted) _exit(0)                                = ?
>
> Nah... No such luck. I'll bet it's artificial. I think you
> could remove that S_IFDIR check and get away with it!

Nope -- what you get is a corrupted filesystem.... Usually, a lost directory
gets put in lost+found, othertimes you get a "corrupted inode", and if the
inode is cleared you then find every file that was contained in the directory
that used to be the inode, is now in lost+found.

The only place I can think of that this might not happen are those filesystems
that don't use the UNIX style tree structure.