gittup/tup — comment on commit 31374181fefd8561bab7b01c3aa508973afd23f4
File: src/tup/server/fuse_server.c line 241
By gittup:

On Tue, Dec 20, 2011 at 1:27 AM, Anatol

wrote:
> Hi
>
> On Mon, Dec 19, 2011 at 6:31 PM, gittup <
> reply@reply.github.com
>> wrote:
>
>> The only part related to fuse4x I think is that I use -oallow_other in
>> fuse_server.c instead of -oallow_root like on linux. The other OSX
>> issue is that it doesn't support bind-mounts, which is just an OS
>> limitation, not a fuse4x limitation. To see the behavior, change the
>> -oallow_other to -oallow_root, build tup, and then you have to make
>> the tup executable owned by root and suid:
>>
>> sudo chown root:wheel tup; sudo chmod u+s tup
>>
>> (At some point there may be a new TUP_CONFIG variable to do this
>> automatically when building, but obviously it needs sudo to work so it
>> would be off by default).
>>
>> Now that tup is suid you can run a test case:
>> $ ./test.sh t4000-compile-c.sh
>> --- Run t4000-compile-c.sh ---
>> .tup repository initialized.
>> [ tup ] Scanning filesystem...0.001s
>> [ tup ] Reading in new environment variables...
>> [ tup ] Parsing Tupfiles...
>> [ 1/1 ] .
>> [ tup ] No files to delete.
>> [ tup ] Executing Commands...
>> [ 1/2 ] gcc -c foo.c -o foo.o
>> mount: Operation not permitted
>> tup error: Unable to bind-mount /dev into fuse file-system.
>> *** tup errors ***
>> *** Command ID=8 failed with return value 1
>> *** Failed to update!
>> *** t4000-compile-c.sh failed
>>
>> When I use -oallow_other it seems to work as expected.
>>
>
> Ok I think I fixed the issue with permissions. Could you please install
> this developer version of fuse4x and test it
> http://dl.dropbox.com/u/3842605/Fuse4X-0.8.14.dmg If everything ok I push
> my changes to master branch.

Yes, that fixes the issue.

>
> In the future if you see "something wrong" with fuse4x - let me know it.
> Fuse4x still has a lot of bugs that need to be fixed.

Sorry, when I was searching around online I found this thread:
http://fuse4x.1054701.n5.nabble.com/Strange-behavior-with-Fuse4X-sshfs-on-Lion-td4638864.html#a4639112

It sounded like the suggestion there was to switch from allow_root to
allow_other, so I tried that and it worked. I just assumed it was the
same issue (ie: a bug in Lion, not in fuse4x). Otherwise I would have
reported it on the mailing list.

>
>
> BTW On my macosx 10.6 I feel like tests are slower than they used to be.
> Not really slower but when I run tests the rest of the system freezes - I
> cannot run browser or run other command in the Terminal.

Did you make tup owned by root and add suid? If so, it will run all
subprocesses in a chroot. This is necessarily slower, and
unfortunately there isn't much tup can do about it. For example, just
doing ./build.sh on my machine takes ~11s. If I use the fusexmp.c
example to make a loopback mount, and then chroot into that mount, the
same ./build.sh script takes ~17s. Note that this doesn't actually run
tup, it is just running a shell script inside of a chroot vs outside.
So when tup runs in chroot mode, it inherits this overhead from fuse
(and then adds on some more for dependency management). If you just
run 'tup upd' again it should regenerate the tup executable without
the suid bit set.

Although the chroot part is in tup, it doesn't yet support
dependencies on files outside of the tup hierarchy. I am planning to
add that as an option in the future, so for cases where you want full
system wide dependencies you can run in a chroot and capture
dependencies on files like /usr/bin/gcc and such. It will be much
slower than usual, but also much harder to break (and no need for
clean builds on system upgrades).

>
> Maybe it is because I see a lot of unmounted devfs points?
>
> $ mount | grep devfs | wc -l
> 991

Oops, that is definitely a bug. Should be fixed in the latest master.
I'm not sure how to clean those stale entries out without rebooting,
though.

-Mike