Patch seems to work, might want more testing.
It probably should not be applied without a discussion, especially
as no filesystem in kernel tree wants this. I am working on a fs that does.
---
--- include/linux/fs.orig.h 2006-02-27 21:45:26.000000000 -0800
+++ include/linux/fs.h 2006-02-27 21:48:17.000000000 -0800
@@ -83,6 +83,8 @@
/* public flags for file_system_type */
#define FS_REQUIRES_DEV 1
#define FS_BINARY_MOUNTDATA 2
+#define FS_ALLOW_HLINK_DIR 4 /* FS will accept hard links to directories */
+#define FS_ALLOW_USER_HLINK_DIR 8 /* And it makes sense for regular users */
#define FS_REVAL_DOT 16384 /* Check the paths ".", ".." for staleness */
#define FS_ODD_RENAME 32768 /* Temporary stuff; will go away as soon
* as nfs_rename() will be cleaned up
--- fs/namei.c.orig 2006-02-27 21:55:26.000000000 -0800
+++ fs/namei.c 2006-02-27 22:08:27.000000000 -0800
@@ -2107,7 +2107,14 @@
if (!dir->i_op || !dir->i_op->link)
return -EPERM;
if (S_ISDIR(old_dentry->d_inode->i_mode))
- return -EPERM;
+ {
+ if (!(old_dentry->d_sb->s_type->fs_flags & FS_ALLOW_HLINK_DIR))
+ return -EPERM;
+ if (!(old_dentry->d_sb->s_type->fs_flags
+ & FS_ALLOW_USER_HLINK_DIR)
+ && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ }
error = security_inode_link(old_dentry, dir, new_dentry);
if (error)
Joshua Hudson wrote:
> Patch seems to work, might want more testing.
> It probably should not be applied without a discussion, especially
> as no filesystem in kernel tree wants this. I am working on a fs that does.
>
This is backwards I think. This is not disallowed because there are
no filesystems that want it. Linux doesn't want it so it is disallowed
by the vfs.
You have to put forward a case for why we want it, rather than show us
your filesystem that "wants" it. Right?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
Nick Piggin <[email protected]> wrote:
> Joshua Hudson wrote:
> > Patch seems to work, might want more testing.
> > It probably should not be applied without a discussion, especially
> > as no filesystem in kernel tree wants this. I am working on a fs that does.
> This is backwards I think. This is not disallowed because there are
> no filesystems that want it. Linux doesn't want it so it is disallowed
> by the vfs.
Right.
> You have to put forward a case for why we want it, rather than show us
> your filesystem that "wants" it. Right?
Nope. The "why a FS might want it" part is pretty clear (we do have
symlinks to directories as a poor man's substitute, after all), the "why it
can't be allowed" part is the tricky one...
- It creates the possibility of loops ==> The garbage collection of unused
stuff can't be done just by reference counts (as today), and gets very
hairy... and needs a /lot/ of memory.
- Loop detection/breaking in a general graph /can't/ be done while it is
being updated, and they thake a long time (and lots of memory)
- Can't just assume that by locking in the directory/subdirectory/... order
no deadlocks are possible, and traversing the filesystem for surgery gets
to be one operation at a time, not concurrent as today
- A while back (in one of the recurrent ReiserFS flamewars Re: Files as
directories, which creates exactly the same situation when linking to a
file-is-a-directory) somebody (Linus? Ted T'so?) showed that certain
simple operations would potentially require exponential time or memory (I
forget which), and thus the idea was out of the question.
Sure, the situations that give rise to the problems are rather clear-cut,
and could be disallowed, but the result for the user would have seemingly
random restrictions. IMVHO it is much better to have a restricted system
with a simple conceptual model than a more relaxed one, but with hard to
understand corner cases it doesn't allow.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Nick Piggin wrote:
>>Patch seems to work, might want more testing.
>>It probably should not be applied without a discussion, especially
>>as no filesystem in kernel tree wants this. I am working on a fs that does.
> This is backwards I think. This is not disallowed because there are
> no filesystems that want it. Linux doesn't want it so it is disallowed
> by the vfs.
> You have to put forward a case for why we want it, rather than show us
> your filesystem that "wants" it. Right?
Agreed. Mostly this is because the design of unix directory semantics
preclude it from being possible. You have exactly one ".." entry. More
than one ".." would mean confusion (which does ".." refer to?). A
different name would confuse more programs.
The VFS is presenting collections of arbitrary filesystems as unix
filesystem, it is not a generic abstraction for any kind of storage
system that is extended to encompass novel approaches to filesystem
structure.
So if you wanted to access such a filesystem via Linux you would need to
present this non-unix idea of directory hard links through some kind of
ioctl etc.
Besides, we already have bind mounts, which are in many ways like a
directory hard link (and, in many other ways, unlike one).
Sam.
Horst von Brand wrote:
> Nick Piggin <[email protected]> wrote:
>
>>Joshua Hudson wrote:
>>
>>>Patch seems to work, might want more testing.
>>>It probably should not be applied without a discussion, especially
>>>as no filesystem in kernel tree wants this. I am working on a fs that does.
>
>
>>This is backwards I think. This is not disallowed because there are
>>no filesystems that want it. Linux doesn't want it so it is disallowed
>>by the vfs.
>
>
> Right.
>
>
>>You have to put forward a case for why we want it, rather than show us
>>your filesystem that "wants" it. Right?
>
>
> Nope.
What do you mean nope?
I know why unix didn't allow loops in the filesystem tree. I'm just
saying that you have to justify a feature before adding it. If he was
able to nicely solve problems with loops and show some application
that benefits from it, then it could be considered for Linux.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
>
> I know why unix didn't allow loops in the filesystem tree. I'm just
> saying that you have to justify a feature before adding it. If he was
> able to nicely solve problems with loops and show some application
> that benefits from it, then it could be considered for Linux.
>
It's bad IMO. Consider someone doing `ln . foo`. Find algorithms could not
stop, because they would be recursing until 1. dawn 2. PATH_MAX is reached
3. a user option says so (e.g. -maxdepth). Symlinks provide at least one
way to know when not to endlessy dive into directories.
Jan Engelhardt
--