Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

hmmm....should ln work?

12 views
Skip to first unread message

mark benedetto king

unread,
Mar 16, 1994, 2:52:33 AM3/16/94
to
I ran into a problem w/ln, so before I posted here, I got the very latest
gnu fileutils (3.8.4f), and made them. I'm running a slackware/SLS/me
distribution with a pre-1.0 kernel.

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?

-ki...@tinuviel.cs.wcu.edu

Frank Lofaro

unread,
Mar 16, 1994, 4:51:11 PM3/16/94
to

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.


Linus Torvalds

unread,
Mar 17, 1994, 4:07:03 AM3/17/94
to
In article <1994Mar16.2...@unlv.edu>,

Frank Lofaro <ftlo...@unlv.edu> wrote:
>
>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

0 new messages