Messages in this thread | | | Date | Wed, 25 Aug 2004 14:00:01 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: silent semantic changes with reiser4 |
| |
On Wed, 25 Aug 2004 viro@parcelfarce.linux.theplanet.co.uk wrote: > > On Wed, Aug 25, 2004 at 01:22:55PM -0700, Linus Torvalds wrote: > > > > It's the UNIX way. > > Not if you allow link(2) on them.
Heh. I don't think that's a very strong argument against being "unixy", considering how traditional unix _used_ to handle directories.
mkdir/rmdir/rename only came later. Now, obviously they did come later for a good reason, but still..
The interesting part is that thanks to the dcache, we should be perfectly able to actually _see_ circular links etc, so some of the problems with linking directories should actually be quite solvable - something that is _not_ true for a traditional UNIX VFS layer.
Of course, the dcache introduces some new problems of its own wrt directory aliasing, but I don't actually think that should be fundamental either. Treating them more as a "static mountpoint" from an FS angle and less as a traditional Unix hardlink should be doable, I'd have thought.
(Also, it's entirely possible that the filesystem may not support some of the more esoteric linking/renaming operations. For example, in a traditional xattrs setup where the xattr is linked on-disk with the file it is associated with, you simply _can't_ link it somewhere else, or rename it to any other directory. That's not a VFS layer issue, obviously, but I thought I'd bring up the point that file-as-dir cases may have limitations that normal files don't have).
> And not if you design and market your stuff as a general-purpose > backdoor into kernel.
Now that's a separate argument, and not one I'm personally interested in arguing at least right now. I haven't actually looked at the reiser4 code, so I'm really _only_ arguing against special-case attributes.
Linus - 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/
| |