On Thu, Jul 21, 2011 at 9:34 PM, Erik Larsson <[email protected]> wrote:
> **
> Hi,
>
> Anatol Pomozov wrote 2011-07-22 02.33:
>
> FYI: The upcoming version of Fuse4X will include additional *.dylib files
> that are binary compatible with MacFUSE [1] so any application will work
> with Fuse4X without recompiling. Fuse4X is going to include compatible
> MacFUSE.framework as well [2].
>
>
> Ok, so what is the difference between OSXFUSE and FUSE4X now again? :)
>
Fuse4X project exists for 1.5 months already, while OSXFUSE still not alive.
The technical differences that I remember from top of my head:
- fuse_mount operation made async. Without it fuse_mount() function is
blocked until fuse daemon responses with FUSE_INIT. But in this case you
cannot use low-level fuse API like this one:
fuse_mount(); fuse_new(); fuse_loop();
- macfuse/osxfuse blocks SIGCHLD. This is just a horrible macfuse decision
- you cannot use macfuse/osxfuse in multithread applications (wait()
function does not work).
- removed mount_fusefs binary. In linux and FreeBSD mount() syscall is
privileged so one needs a binary with suid bit that user can use for
mount(). Darwin does not need it - mount logic can be made much more simple
and faster.
- uninitialization logic in macfuse is just horrible. fuse4x simplifies it
and makes straight.
- a bunch of code cleanup in kext/libfuse
- public header macfuse_darwin.h in macfuse replaces semaphores with its
own implementation based on pthreads (it is actually slightly changed libsem
library from GNU Hurd). Fuse4x removes it as it is not a responsibility of
the fuse library publicly replace Darwin core functionality.
- one more thing that I do not like in macfuse is fuse.pc vs fuse_i64.pc
thing - macfuse (and I believe osxfuse) distributes 2 dynamic libraries, one
for 32 another for 64 bit inodes. Instead one should use symbol variants.
See more info here
http://developer.apple.com/library/mac/#releasenotes/Darwin/SymbolVariantsRelNotes/_index.html
OSXFuse is just rebranded Tuxera macfuse and nothing more. It is fully
backward compatible with macfuse though, while fuse4x drops some functions
and changed behavior described above.
Benjamin decided to follow "osxfuse is not fuse" way [1], while fuse4x
follows "fuse4x *is* fuse". So osxfuse puts itself into trap when it have to
keep and support all macfuse bugs in sake of backward compatibility with
macfuse. Fuse4x does not try to be fully backward compatible with macfuse,
instead it tries to be compatible with the upstream implementation.
The fact is that macfuse/osxfuse is not compatible you can check by trying
to run following program https://gist.github.com/1101067 It runs perfectly
fine on the upstream Linux while hangs with macfuse/osxfuse.
You might ask "What about existing programs that currently use macfuse? Do
they need to be recompiled?" If your filesystem works fine with MacFUSE just
continue using it - no need to do any changes. There is an unofficial build
from Tuxera that works fine with Lion. But if you care about being
compatible with the upstream fuse - use fuse4x. Applications that use fuse4x
can coexist with applications that use macfuse.
[1] http://osdir.com/ml/macfuse/2011-05/msg00032.html
The next release of fuse4x will add back some of the removed functions and
provide additional ABI compatible dylibs. It is needed to people who does
not want to use macfuse from Tuxera for some reason.
FYI 2: there is an ongoing conversation with Miklos about merging
> MacFUSE/Fuse4X changes to the upstream project (don't forget that MacFUSE is
> a fork itself). It'll take some time though, at least a few months.
>
>
> This would be the libfuse changes I assume. This would be much welcome, but
> please make sure that generic MacFUSE changes are merged and not changes
> that diverge between MacFUSE / FUSE4X / OSXFUSE (at least we need to agree
> between FUSE4X and OSXFUSE on pushing such changes upstream as it affects us
> both).
>
>
> [1] Well, it won't be 100% compatible. Fuse4X has a few changes in fuse
> behavior (e.g. async mount(); fuse4x does not block SIGCHLD anymore; does
> not changes semaphores implementation from Darwin; has some
> de-initialization changes...). But assuming that the most filesystems are
> written for Linux (encfs, truecrypt, sshfs,...) with the upstream fuse
> behavior in mind it these changes will not break them. Even more - as Fuse4X
> follows standard closer these applications will work more stable and have
> less problems.
>
> [2] It is still not clear to me the legal question around MacFUSE name.
> This brand belongs to Google and Amit explicitly asked not to use it so I am
> not sure if I can distribute/change MacFUSE.framework. So I need to clarify
> it with Google first or just wait until Google contacts and asks to
> remove MacFUSE.framework from the distribution package.
>
>
> MacFUSE isn't really a registered trademark of either Amit or Google, is
> it? (I sincerely doubt that they would find MacFUSE to be worth protecting
> as a trademark.)
> It's not realistic to change all occurrences of 'MacFUSE' into something
> else, as this would mean that we have no chance of being compatible with
> existing software... especially in the case of MacFUSE.framework.
>
> How far is the 'rebranding' expected to go? With this strict interpretation
> of brand ownership and usage we are all handcuffed when it comes to being
> compatible with existing binaries.
> (Amit is as always welcome to speak his mind... if he hasn't terminated his
> membership in this group.)
>
> Regards,
>
> - Erik
>
>
> On Thu, Jul 21, 2011 at 1:30 AM, Benjamin Fleischer <[email protected]>wrote:
>
>> Hi Josh,
>>
>> check out OSXFUSE. There has been some quite some messages in the past
>> about OSXFUSE on this mailinglist.
>> OSXFUSE is compatible with Leopard through Lion and features a
>> compatibility layer to be compatible with "all" existing MacFUSE filesystems
>> ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary
>> compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be
>> recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
>>
>> OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik
>> (the author of the rebel branch) and I are the the owners of the OSXFUSE
>> project.
>>
>> Homepage will be http://osxfuse.github.com
>> The GitHub is https://github.com/osxfuse
>> Our google group is http://groups.google.com/group/osxfuse-group
>>
>> You can find some instructions on building OSXFUSE in the group. If you
>> need assistance, feel free to ask. But please hold off from distributing any
>> builds. The update mechanism has not been set up and there are a few other
>> things I'm working on right now. Non the less OSXFUSE's core feature is
>> already fully functional.
>>
>> I will post an official beta in in the next two or three days. More
>> information to come. Just thought I'd let you know. We don't need another
>> MacFUSE fork/build around. The situation is already a mess as it is. But I
>> will highly appreciate you spreading the word when we are ready, in a few
>> days. You blog post has helped quite some people.
>>
>> Regards,
>> Benjamin
>>
>> Am 21.07.2011 um 07:02 schrieb Josh:
>>
>> Hello, I am the author of the blog post jb links to below. The direct
>> link to the page is here:
>>
>>
>> http://www.offthehill.org/articles/2010/12/31/macfuse-for-64-bit-snow-leopard
>>
>> I get many thank you comments from people, so I can only hope it helps
>> them. I can't take any credit for the work however, since I just
>> compiled Tuxera's 'rebel' source code.
>>
>> I am trying to figure out how to compile for Lion, and I've made some
>> progress, but so far I am stuck on a check in the build script, I'll
>> have to start understanding how it works I guess.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "MacFUSE" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/macfuse?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MacFUSE" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/macfuse?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MacFUSE" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/macfuse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"MacFUSE" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/macfuse?hl=en.
