[PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[Joshua Hudson]

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)

Re: [PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[Nick Piggin]

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 

Re: [PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[Horst von Brand]

Nick Piggin <nickpiggin@yahoo.com.au> 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

Re: [PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[Nick Piggin]

Horst von Brand wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> 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 

Re: [PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[Jan Engelhardt]

>
> 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
-- 

Re: [PATCH 02/27] allow hard links to directories, opt-in for any filesystem

[Sam Vilain]

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.