Messages in this thread | | | Date | Thu, 7 Aug 1997 10:17:48 -0400 (EDT) | From | Fila Kolodny <> | Subject | Re: 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-----
| |