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:0.640 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site