lkml.org 
[lkml]   [2003]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: FS: hardlinks on directories
    Date
    On Monday 04 August 2003 18:34, Stephan von Krawczynski wrote:
    > On Mon, 4 Aug 2003 16:16:39 -0500
    >
    > Jesse Pollard <jesse@cats-chateau.net> wrote:
    > > > > 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?
    > >
    > > Mount -bind only modifies the transient memory storage of a directory. It
    > > doesn't change the filesystem. Each bind occupies memory, and on a
    > > reboot, the bind is gone.
    >
    > What kind of an argument is this? What difference can you see between a
    > transient loop and a permanent loop for the applications? Exactly zero I
    > guess. In my environments nil boots ought to happen.

    simple .. tar --one-file-system will not process past a mount point.

    > This is the reason why I would in fact be satisfied with mount -bind if
    > only I could export it via nfs...

    it's a MOUNT point. NFS doesn't export across mount points just as it doesn't
    allow exporting a NFS mounted directory.

    >
    > > > 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...
    > >
    > > been there done that, is is a "big mess of loops".
    > >
    > > And you can't prevent the loops either, without scanning the entire
    > > graph, or keeping a graph location reference embeded with the file.
    >
    > Or marking the links as type links somehow.
    >
    > > Which then breaks "mv" for renaming directories... It would then have to
    > > scan the entire graph again to locate a possble creation of a loop, and
    > > regenerate the graph location for every file.
    >
    > There should be no difference if only a hardlink is simply marked as such
    > by any kind of marker you possibly can think of.

    think about what happens with a "rm -rf name". If there are two parents you
    cant remove the other parents link without first finding it. hard links
    do not have a marker.
    -
    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:0.027 / U:0.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site