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

Hi

On Tue, Dec 20, 2011 at 6:17 PM, gittup <
reply@reply.github.com
> wrote:

> 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.
>

Indeed the issue described in the post is a bug in Lion, but it was fixed
some time ago. But you discovered another bug. I am going to submit it to
fuse4x and release the fix in 0.8.14 (hopefully in 2-3 days).

> 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.

Yes I was testing it with suid. Thanks for the explanation. I think it
worth sharing this info in the mailllist.

> 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.
>