lkml.org 
[lkml]   [2003]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: FS: hardlinks on directories
    On Mon, 4 Aug 2003 15:04:28 +0100 (BST)
    Anton Altaparmakov <aia21@cam.ac.uk> wrote:

    > For a start the kernel VFS dcache would break because you end up with
    > multiple entries for each inode, one entry for each parallel directory
    > tree. Read-only you are just about able to get away with it (been there,
    > done that, don't recommend it!) but allow files to be deleted and it will
    > blow up in your face.

    I cannot comment, I have no inside knowledge of it.

    > You ask for examples of applications? There are millions! Anything that
    > walks the directory tree for a start, e.g. ls -R, find, locatedb, medusa,
    > du, any type of search and/or indexing engine, chown -R, cp -R, scp
    > -R, chmod -R, etc...

    There is a flaw in this argument. If I am told that mount --bind does just
    about what I want to have as a feature then these applictions must have the
    same problems already (if I mount braindead). So an implementation in fs cannot
    do any _additional_ damage to these applications, or not?

    My saying is not "I want to have hardlinks for creating a big mess of loops
    inside my filesystems". Your view simply drops the fact that there are more
    possibilities to create and use hardlinks without any loops...

    Regards,
    Stephan
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:47    [W:4.160 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site