Moritz Schulte <[EMAIL PROTECTED]> writes: > Actually I was not thinking about making ".." go to the unionfs, but > this surely seems like a good idea. > > > If it's a translator (of any kind, including symlink) then it does > > the translator linkage *itself*, just as diskfs/netfs does it. > > I don't understand how that works in detail. You mean, unionfs takes > the job away from the underlying filesystems and manages _their_ > translators with nodes in _unionfs_? Right now, unionfs only manages > virtual directories.
Well, that's what I was suggesting. But now that I think more about it, it seems wrong. Though, in the case of symlinks, it's right (because it seems like ".." should go to the unionfs). But symlinks are just a kind of translator (even though short-cutted by diskfs). It seems wrong to me that you'd get a separate translator started up, once under the aegis of the union fs, and once under the aegis of the "real" location of the file. What we really want is for the user to do a retry of the name as it exists in the "real" location, and then if that results in ENOENT, we want the user to return back to the filesystem for another name to try. Perhaps we should add a new FS_RETRY type. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
