Messages in this thread | | | From | Jesse Pollard <> | Subject | Re: FS: hardlinks on directories | Date | Mon, 4 Aug 2003 16:23:42 -0500 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |