Comments within quoted text.

On Tue, 7 Apr 2009 13:23:37 -0400 (EDT)
Mario Charest <community-noreply@qnx.com> wrote:

> 
> 
> > -----Original Message-----
> > From: Will Miles [mailto:community-noreply@qnx.com]
> > Sent: April-07-09 12:41 PM
> > To: technology-networking
> > Subject: Re: localhost
> > 
> > I think the basic issue falls out because ln always tries to lstat()
> > the destination, to make sure that it doesn't already exist.  However,
> > in the case of qnet, instead of returning ENOENT when it can't find the
> > destination, it returns EHOSTUNREACH; this confuses ln, so it bails.
> > The real question for the networking gurus is: is this the right
> > behaviour?  Shouldn't the /net mount point return ENOENT like any other
> > filesystem?  Or should ln (and anyone else who might operate on /net)
> > treat EHOSTUNREACH the same as ENOENT?
> 
> Well I would expect the -P option of ln to totally disregard this.  It's suppose to be handled by the process manager,
 why care if the basename (/net) exist or not.
> 

It's the full name it's checking, not the base name.  It wants to be
sure that "/net/localhost" isn't a file that already exists before it
creates a symlink with that name; the problem in this case is that
qnet doesn't return 'ENOENT' like it's expecting if the file doesn't
exist.  I agree that it would be practical to allow ln -sP to skip these
checks though - and additionally to allow procmgr symlinks to be added
'in front of' or 'behind' a file or directory that already exists,
similar to the way mount points can be overlaid.  A clever system
administrator could compose a poor man's failover system with this
facility...

Sounds like it's time to propose a patch to ln!  

-Will



-- 
Will Miles <wmiles@sgl.com>

Or simply write a one-line code of my_ln_sP.c that calls
pathmgr_symlink().

I've created a PR on ln. Thanks.

Thanks
Weijie


-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com] 
Sent: April 7, 2009 1:24 PM
To: technology-networking
Subject: RE: localhost



> -----Original Message-----
> From: Will Miles [mailto:community-noreply@qnx.com]
> Sent: April-07-09 12:41 PM
> To: technology-networking
> Subject: Re: localhost
> 
> I think the basic issue falls out because ln always tries to lstat()
> the destination, to make sure that it doesn't already exist.  However,
> in the case of qnet, instead of returning ENOENT when it can't find
the
> destination, it returns EHOSTUNREACH; this confuses ln, so it bails.
> The real question for the networking gurus is: is this the right
> behaviour?  Shouldn't the /net mount point return ENOENT like any
other
> filesystem?  Or should ln (and anyone else who might operate on /net)
> treat EHOSTUNREACH the same as ENOENT?

Well I would expect the -P option of ln to totally disregard this.  It's
suppose to be handled by the process manager, why care if the basename
(/net) exist or not.

> 
> Mario, for your specfic case it might be the most expedient route to
> compile your own little application that calls pathmgr_symlink()
> directly without doing all the checks that ln does.  While it's rarely
> a good long-term plan to compile your own system management utilities,
> I think it might be a lesser evil than remounting qnet.

We'll just live without /net/localhost.  Funny that nobody else felt the
need for such a feature,  I mean it's in TCP/IP and even in QNX4 ( node
0 is the local node). Programma

> 
> Just my $0.02,

Input appreciated !

> 
> -Will
> 
> 
> On Tue, 7 Apr 2009 10:58:20 -0400 (EDT)
> Mario Charest <community-noreply@qnx.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Weijie Zhang [mailto:community-noreply@qnx.com]
> > > Sent: April-07-09 10:54 AM
> > > To: technology-networking
> > > Subject: RE: RE: localhost
> > >
> > > In fact, we don't even need to "mkdir /net" if we are using the "-
> sP"
> > > to
> > > the ln command because "-P" makes the link go into the proc
manager
> > > prefix tree.
> > >
> > > So the step is,
> > > 1) before qnet is mounted, create the symlink, "ln -sP /net/mybox
> > > /net/localhost".
> > > 2) start qnet.
> > >
> >
> >
> > Ok but isn't odd that -sP doesn't work afterward?
> >
> > That being said for us that is no possible because the qnet is first
> started with a default hostname in the .boot file, and then when we
get
> access to the file system the hostname is changed.  I guess I could
> change that so that we umount qnet and then mount it again with the
> proper hostname.
> >
> > > Thanks
> > > Weijie
> > >
> >
> >
> > _______________________________________________
> > Technology
> > http://community.qnx.com/sf/go/post26232
> >
> >
> 
> 
> --
> Will Miles <wmiles@sgl.com>
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post26248
> 


_______________________________________________
Technology
http://community.qnx.com/sf/go/post26252