lkml.org 
[lkml]   [1997]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Msdos name alias patch for 2.1.48
    -----BEGIN PGP SIGNED MESSAGE-----

    On Thu, 7 Aug 1997, Janos Farkas wrote:

    > On Wed, Aug 06, 1997 at 10:12:04AM -0700, Linus Torvalds wrote:
    > [ Andreas Schwab writes:]
    > > > A better approach might perhaps be if xxx_lookup not only
    > > > creates the dentry for the original name, but also for a `canonical' name,
    > > > ie., the name it would return in xxx_readdir.
    > >
    > > I've been thinking along a slightly different line.
    > >
    > > What could be done is that "lookup" will just match any of the canonical
    > > names, but when it notices that it has matched the same inode twice, it
    > > just throws away the new dentry and returns the old dentry instead. That
    > > way only one dentry would ever be active at a time.
    There should be only one canonical name for FS's like vfat and for that
    Linus's suggestion is proper, but the matching should never be done by
    inode.
    >
    > Hmm.. That would make dentries less and less useful, in my eyes. Currently,
    > they at least try to imitate Unix (single inode -> multiple dentry possible).
    > The scheme above would mean it would be impossible to differentiate between
    > hard links (or at least their names from their dentries). And for nfs, even
    > more difficulties may come if someone renames a still-in-use file remotely?
    >
    > At least only one of them would live, just as well as if it was hardlinked?
    >
    > --
    > Janos - Don't worry, my address works. I'm just bored of spam.
    >

    Type Bits/KeyID Date User ID
    pub 768/8B29D4BD 1997/07/23 Fila Kolodny <fila@ibi.com>
    Fila Kolodny <filak@idt.net>

    - -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: 2.6.3a

    mQBtAzPWSAAAAAEDAMzh24XwtxbDTMnS2Cec7XNQsAxXGc5DrrL5+3RZOyYd/EBp
    jIJDTciIe3YJRf9ceVUj4SmkiPh0Ux0Szft/L9kEQoXVRfGJQ1uK6YMIv+1QHgkn
    iI2SbIl13F6+iynUvQAFEbQbRmlsYSBLb2xvZG55IDxmaWxhQGliaS5jb20+iQB1
    AwUQM9ZIAHXcXr6LKdS9AQEV9gL/Y2UJhSivrZ0LtvrHK1VKTaXZqDoQnQqyyOlQ
    /a8spMZ9a5X2OohpvsD1y68Qn4TLdb49mHv3owKKKJ/Lgf3LTrh0XfyJEMMhG4+Q
    brLTRJ8WHLPSheAKufpSRcVob4pjtBxGaWxhIEtvbG9kbnkgPGZpbGFrQGlkdC5u
    ZXQ+iQB1AwUQM99C/XXcXr6LKdS9AQGx2QL9Eh17CIjbb/nG82uhMTDj2KDOv1Yy
    SB2dwfacpEIyztPheL+vE3HpvP5an4E2TNR8p6a7kiLBWTHaodSDqiF0jj+dmRJa
    dULcFhVWHr1EUOTabm+F6Vn4CqkOwF78MWTG
    =b7XE
    - -----END PGP PUBLIC KEY BLOCK-----

    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.3ia
    Charset: noconv

    iQB1AwUBM+nZFXXcXr6LKdS9AQEjOQL/cFYBLdizxZadu5FcZh+xPc2r8bz6iqsV
    mpkvGTq7EumlFwP+o7vbpk1qAMDdchwZCvtO+Th6CAlBAJOB/D8rMu7V1OCeuP1j
    1ipLO5oj0c944R1cYjUqbOty+RBgkdbn
    =cW5o
    -----END PGP SIGNATURE-----


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