[9fans] getting at Windows files from VMware-hosted Plan 9

[Mike Haertel]

First of all, here is a cute 1-liner for running u9fs without inetd
(useful if your local system administrator refuses to run u9fs from inetd,
or you hate rhosts-style authentication, or whatever...)

% ssh myname@remotehost u9fs -a none -u myname <[0=1] | echo 0 > /srv/remotehost
% mount /srv/remotehost /n/kremvax

I thought people might be interested in how I'm using this: I have an ssh
daemon running on my Windows box at work, courtesy of Cygwin. I run Plan 9
under VMware on the same box.

I ported u9fs to Windows, again courtesy of Cygwin. (Main changes: Cygwin has
no setre[ug]id(), no ruserok(), no <inttypes.h>, and no pread()/pwrite().
Diffs available upon request.)

So, in my VMware-hosted Plan 9 running under Windows, I do the following:

% ssh Administrator@windows u9fs -a none -u Administrator <[0=1] | echo 0 > /srv/windows
% mount /srv/windows /n/kremvax
% bind /n/kremvax/cygdrive/c /n/c

and thus I can use /n/c from VMware to look at the windows partition, just
as if Plan 9 were running on the bare hardware.

Moreover, this hack allows Plan 9 to see the contents of any SMB file server
that the host Windows environment can access. Very useful if you're stuck
in a mixed network of evil operating systems.

[Russ Cox]

That's really cute. Does the Windows ssh you have support
port forwarding, so that sshnet would work too?

Russ

[rob pike, esq.]

Nice!

<[0=1] | echo 0 > /srv/remotehost

is a clever trick. Another blow for textual interfaces!

-rob

[Mike Haertel]

>That's really cute. Does the Windows ssh you have support
>port forwarding, so that sshnet would work too?

Yup. It's just OpenSSH ported to run under Windows.

[Scott Schwartz]

<[0=1] | echo 0 > /srv/remotehost

While this is cool, I have to admit that I never really liked
bidirectional pipes, because if you want to close half of the connection,
you either need something like bsd's shutdown(), or a way to recover
your control file which hopefully will let you half-close.

[Mike Haertel]

>While this is cool, I have to admit that I never really liked
>bidirectional pipes, because if you want to close half of the connection,
>you either need something like bsd's shutdown(), or a way to recover
>your control file which hopefully will let you half-close.

I'm curious? Why does this bother you? Just let half the connection
go unused.

My very first reaction to bidirectional pipes, when I first heard of
them in some journal article about v8 Unix many years ago, was: wow,
that is such an obvious win, why wasn't it done years ago?

The only thing I can think to explain your position is that it's a
semi-religious issue, rather like dynamically typed vs. staticly
typed languages: some people like the greater flexibility associated
with type checks only at the point you actually try to use the
value, whereas others want to get their error messages right away.
And some people like the flexibility of bidirectional pipes, whereas
others would like to get errors back from "incorrect" read and write
system calls immediately.

[Geoff Collyer]

A reason to close one direction of a pipe is if the program
at the other end of the pipe is a filter (think "ssh system command")
and you need it to see EOF before you can be sure of getting
all its output back in the other direction.

[Scott Schwartz]

| I'm curious? Why does this bother you? Just let half the connection
| go unused.

I think that having two open fds is nicer than one open fd and some extra
system calls, because it's impossible to get it wrong. Plan 9 doesn't
have a way to do half-close at all, right? So what if your server was
"sort" instead of "ssh"?

[Russ Cox]

Then you can set it up with a different pipe for
input and for output, and then close the input pipe.
Problem solved. This is what rc does by default.
The <[0=1] explicitly worked around this.

If you'd rather have one fd and don't need the half-open
nonsense, you can use the same pipe for both.

The only real difference is that if you try to write to
a pipe that it only makes sense to read from, you won't
notice when the pipe is bidirectional.

Russ

[for...@caldo.demon.co.uk]

if it's really a pipe you can write 0 to have it read 0.
just keep that up until it goes away or you become bored.

[Boyd Roberts]

Mike Haertel wrote:
> My very first reaction to bidirectional pipes, when I first heard of
> them in some journal article about v8 Unix many years ago, was: wow,
> that is such an obvious win, why wasn't it done years ago?

That fell straight out of the stream implementation of pipes;
a cross connected stream.

[Steve Kilbane]

> >While this is cool, I have to admit that I never really liked
> >bidirectional pipes, because if you want to close half of the connection,
> >you either need something like bsd's shutdown(), or a way to recover
> >your control file which hopefully will let you half-close.
>

> I'm curious? Why does this bother you? Just let half the connection
> go unused.

Whereas my general dislike isn't so much from the bidirectional aspect
of the pipes, as from the increase in TCP complexity which, as far as I
can tell, doesn't exist for anything other than "rsh host filter". I'd
have expected the simpler protocol would be worth the effort of just
using two streams, in that particular case. I don't care whether the
streams are bi-directional, just that one can be discarded before the other.

steve