according to ln --help, ln -d (or -F, or --directory) should allow the
superuser to create a hard link to a directory. I need to do this for the
purpose of anonymous ftp ( a chroot("/home/ftp"); is executed for anonymous
users, making symlinks useless ). I'm sure it can be done. It just doesn't
work. The error is "Cannot link foo to bar: Operation not permitted".
Is this a kernel problem, an fs problem (that partition is ext2), or
something completely different?
Possible solution:
write a program that changes the source directory's stat.st_mode to that
of a normal file (just or it with 0100000, then and off the 040000...)
links a dest file to it (same inode of course) (via the link() system call),
then changes 'em both to directories once again. Whaddaya think?
The ln -d command is broken due to the kernel. :-( However, patching it is
trivial. Go into the linux/fs/fstype/inode.c file and change the lines
in the link and unlink functions to allow linking/unlinking directories
for the super-user. I don't have my patches available at the moment, but
I have done it. Be careful, it can cause fs corruption.
The hard-linking of directories is very much disallowed, and will so
remain in all official kernels as far as I'm concerned: it's a broken
idea required by old UNIX systems that don't have the "rename()" system
call but need to emulate it with a sequence of "link()/unlink()" calls
(note that you can't make such a sequence atomic, so it wouldn't conform
to the POSIX specs anyway: you *need* to do the rename() operation as a
system call).
Adding hard-linking of directories is not difficult, but the bad points
of it outweigh the usefulness by about 100:1 in my opinion. It's simply
too easy to mess up your filesystem with it, and symlinks usually do the
things hardlinks do much better (you can't use hard-links for chroot'ed
environments due to the behaviour of the ".." entry in them anyway).
If the patches are made available, I'd suggest hiding them somewhere
non-obvious, and marking them as dangerous,
Linus