bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to provide proxy nodes


From: olafBuddenhagen
Subject: Re: How to provide proxy nodes
Date: Mon, 25 Aug 2008 21:31:08 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Sat, Aug 23, 2008 at 12:30:56PM +0300, Sergiu Ivanov wrote:
> On Fri, Aug 8, 2008 at 2:13 AM, <olafBuddenhagen@gmx.net> wrote:
> >On Wed, Aug 06, 2008 at 09:11:08PM +0300, Sergiu Ivanov wrote:

> > > The situation about starting the translator could possibly be
> > > handled similarly to the way netfs_S_dir_lookup handles symlinks.
> > > In case a symlink is found, whose target is stated as a relative
> > > path, netfs_S_dir_lookup just prepends the already existent path
> > > with the path to the target of the symlink.
> >
> > Not sure what you mean here.
> >
> 
> What I wanted to say was that netfs_S_dir_lookup does not give the
> client retry notifications in case it encounters a symlink (except for
> the special case when the path is absolute), and symlinks are
> translators. Probably, we shouldn't return retry notifications either
> in case we encounter translators...

Ah, I think I see now what you mean. It's not really comparable, though.
"Normal" filesystem translators actually implement the filesystem that
stores the symlink -- while the proxy only exposes the underlying
filesystem.

Note that the symlink translator exsists for the sake of filesystems
that do not know about symlinks (fatfs for example), or to allow setting
them as active translators on a readonly filesystem. In normal cases
(like ext2), the symlinks are handled specially by the FS server instead.

If you look up a symlink on a file system that doesn't natively suppport
symlinks, it will handle it like any other active translator, i.e. it
should give you a retry notification.

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]