is anyone able to use 9pfuse on mac os x 10.4 (macfuse 1.5.0)?

in my case, after dial succeeds and mount_fusefs is done,
9pfuse gets stuck waiting to read from fuse device. i've verified
that macfuse is working with sshfs. maybe the handshake has changed?

On May 14, 6:26 pm, 9...@9netics.com (Skip Tavakkolian) wrote:

Earlier builds did work on OS X 10.4, I sure hope the macfuse team
didn't move things around yet again... Though to be honest, the
choice used for default locations on OS X 10.5 finally makes sense.

A warning: MacFuse is very slow on network mount points.

-jas

An alternative to use fuse with network
mount points is to use the o/dav server running on inferno
(this server is now part of the octopus distrib).

I've tested it with the finder several silly programs and it seems to work fine,
although we still consider it alpha (i.e. USE WITH CARE).

Also, faster interaction may be achieved by running o/dav to export
a namespace imported using Op via o/ofs. This saves many rpcs.

// I sure hope the macfuse team didn't move things around yet again.

Oh, you'd like that, wouldn't you? If things just stayed where they were
so you could find them when you wanted them? Sheesh. We listen to
guys like you and we'll end up with all the fun taken out of computing.

it's a little deeper; i'm wading in the mire that is libfuse to see if
i can spot the difference from what 9pfuse has. i'm hoping some
combination of '-o's to mount_fusefs will fix it.

about path changes, 9pfuse cleverly checks and remembers the right one
when access() succeeds. 9pfuse exec's mount_fusefs, which then forks,
but waiting on something. i didn't see any references to fuse.version
in p9p source. what file?

On Fri, May 16, 2008 at 6:21 AM, 9srv.net> wrote:

// i didn't see any references to fuse.version
// in p9p source. what file?

$PLAN9/bin/mount does a 'sysctl fuse.version' to see if it's
already loaded, and looks for the kext explicitly (and as of
v1.3, in the wrong place).

not part of 9pfuse, but support staff.
a

On May 16, 2008, at 12:42 PM, Skip Tavakkolian wrote:

Sadly it's not the mount_fusefs that's failing. I've finally gotten
around to looking at this again now that there's a nice new utility
from Russ that uses 9pfuse.

9pfuse does mount (on Leopard at least) with the latest MacFUSE 1.7
from the goog, and you can watch all the debug details. Unfortunately
9pfuse ends up having similar problems to sshfs, I/O failures when
traversing the mount point. For sshfs it appears as if the latest
MacFUSE keeps everything mounted as root -- so even if you try to
force your uid it ignores it and you end up with a file hierarchy you
can't traverse.

I'll keep looking through to see if the API changed a bit more. There
are MacFUSE filesystems that do work, http://www.friday.com/bbum/2008/01/10/silly-hack-of-the-day-mount-the-obj-c-runtime.../
. That example goes through a different path to initialize the fuse
mount...

-jas

i was able to get Rangboom snsa -- which uses code from Russ' 9pfuse
-- to work with macfuse 1.7 (on os x 10.4.x). the latest 9pfuse has
the patch sqweek sent for xattr; i wonder if that's the problem?

it's depressing to see that Finder acts as demented as Explorer with
incessant directory traversal.

...

On Aug 6, 2008, at 9:31 AM, Skip Tavakkolian wrote:

More depressing that sqweek's change works for OS X 10.4.x but not
with the MacFUSE build for 10.5.x. All I get is:

%% 9pfuse -D $ns/plumb /mnt/plumb
...

%% cd /mnt/plumb
FUSE -> len 8 unique 0x1 uid 501 gid 501 pid 225 Access nodeid 0x1
mask 0x1
<- Twalk tag 0 fid 0 newfid 1 nwname 0
-> Rwalk tag 0 nwqid 0
<- Topen tag 0 fid 1 mode 0
-> Ropen tag 0 qid...

On Wed, Aug 6, 2008 at 10:57 PM, Jeff Sickel corpus-callosum.com> wrote:

...

Is this a 32-bit machine? That's a big frigging inode. I don't have a
clue how mac works, but I recently hit a bug with v9fs where a certain
qid path got mapped to an inode of zero and subsequently disappeared
in the linux vfs layer. Though there was no i/o error there.
-sqweek