[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Oh, that. Blech blech blech.
Blech is also corking.
> And, of course, this matters in just this case! Because it's a
> union, and so the node is found in *two* directories and it's not at
> all clear which one is right.
I'm not sure wether I understand this paragraph correctly. I was
thinking that the primary reason is quite independent from the
unionfs; the reason is simply that the underlying filesystem cannot
resolve a symlink completely (nor can a translater be started with the
correct ".." given).
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.
> Because of this difficulty, I think clearly (heh heh) the right
> thing is the first case.
I agree, that seems more robust.
moritz
--
[EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
