macfuse

Wed Dec 28 22:17:48 PST 2011

Hi,

> Just a thought, but it seems to me a better replacement that fuse4x…
What exactly makes you believe so? If we are talking about technical
aspects then fuse4x is way more superior than macfuse/osxfuse. Where
osxfuse better is *binary* compatibility with macfuse. Fuse4X does not
provide drop-in replacement because I think that it is better to make
fuse4x coexist with macfuse/osxfuse, so old filesystems can still use
macfuse while new filesystems will use fuse4x.

>but I think most of the main people active on macfuse (including a lot of
private forks, such as in tuzera ntfs etc.) moved to it and submitted
patches when macfuse finally died.
I've heard this belief many times but not sure where it comes from. osxfuse
project is developed solely by one person (bfleischer), all changes in the
osxfuse made only by him. If you do not trust me then check the osxfuse
repository. fuse4x as well a single-person project, but at least it has a
few contributions (e.g. from Dan Ports), btw an experienced kernel
developer recently joined fuse4x community with intention to
improve synchronization in 64bit kernel code and make the code much more
scalable.

Ok, here are more technical details on "Fuse4X vs OSXFuse" issue:
1) The main difference is the view and the goals of the project. Fuse4X
main goal is to be "reference implementation" of fuse on macosx. You
probably know that fuse has been developed on Linux (as kernel module +
user library) and most filesystems [1] were developed and tested on Linux.
These filesystems also expect that fuse works the same way on macosx.
Unfortunately the last statement is not true for macfuse. Macfuse was
*never* developed with compatibility in mind - see what Macfuse leader said
[2]
<quote>Amit had long taken a stand that "MacFUSE is not FUSE" and the
2.7.3 release achieves all that he wanted. I think he tried to
avoid promising any type of assured compatibility between FUSE for Linux
et. al. and MacFUSE.</quote>
So filesystem developed on Linux might not work with macfuse or even crash
and in the worst case destroy your data.

Fuse4X started as project that provides "reference fuse implementation for
macosx", it forked off from Tuxera Macfuse codebase and fixed a numerous
incompatibilities, few of them (the most important) : a) macfuse does not
work in multithread applications, b) fuse_mount() in macfuse is synchronous
and waits when the filesystem returns INIT response. The upstream fuse
has asynchronous fuse_mount(), so fuse4x fixed it as well.

2) Fuse4X contains numerous speed-up improvements. e.g. mount() operation
works ~5-6 faster than in macfuse.
3) Fuse4X contains fixes for Lion, fixes a few deadlocks in K64 code.
4) Fuse4X tries to cleanup the macfuse codebase. The macfuse codebase (as
well as the build system) are horrible. Really. I think that 40% of my
activity actually cleaning-up the code and replace WTF places with cleaner
code.
5) Fuse4X works closely with upstream project. One patch originated in
fuse4x has been accepted in the upstream libfuse. A few more are on its
way. I hope that some day macosx will have first class support in libfuse
project [3]
6) The latest wave in fuse4x is to improve K64 code. We had a few deadlock
reports, people suffer from it and say that they cannot use 64bit kernel
because of deadlocks. So fuse4x tries to provide better solution than
currently existing locking mechanism. There is a person who shows intent to
do this.

OSXFuse was forked off from Tuxera Macfuse codebase as well, it contains
fixes for K64 code and for Lion (the Lion compatibility fixes were copied
from Fuse4X project). The main goal of OSXFuse is to be as close to MacFuse
as possible. They provide distribution  that is binary compatible with
macfuse (aka drop-in replacement). But is also means that they continue
"OSXFuse is not Fuse" tradition. It is fine for macosx-only filesystems but
I think unacceptable for cross-platform filesystems.

On Wed, Dec 28, 2011 at 6:59 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Dec 28, 2011, at 19:27, Bradley Giesbrecht wrote:
>
> > On Dec 28, 2011, at 4:14 PM, Dan Ports wrote:
> >
> >> On Wed, Dec 28, 2011 at 10:46:50AM +0000, Chris Jones wrote:
> >>> Has anyone consider moving to osxfuse, instead of fuse4x ? It also was
> born out of the death of macfuse, but shares a lot of code with MacFuse but
> has been updated a lot to, for instance work with 64 bit kernels etc.
> >>>
> >>
> >> Yes, it would be nice to have a port for osxfuse as an option too. If I
> >> had the time, I'd work on it, but I don't right now...
> >
> > I started a osxfuse port this morning then had to move on to other
> things.
> >
> > Executing the build.sh script is failing for me.
> > Build settings from command line:
> >    ARCHS = i386 x86_64
> >    GCC_VERSION = 4.2
> >    MACOSX_DEPLOYMENT_TARGET = 10.6
> >    SDKROOT = /Developer/SDKs/MacOSX10.6.sdk
> >
> > OSXFUSEBuildTool(smalldist) failed: xcodebuild cannot build
> configuration Release.
> >
> > Should someone/me open a ticket as a place to contribute/improve the
> future osxfuse port?
>
> Sure, if you don't want to work on it anymore, that would be good to
> ensure it doesn't get lost.
>
> This particular error sounds like you may just need to change the value of
> xcode.configuration to the correct value for this Xcode project file.
>
> http://guide.macports.org/#reference.portgroup.xcode.keywords
>
> Or, maybe there is more error that you haven't shown us.

It would be really great to make sure that filesystems and tools that use
fuse work both on fuse4x and osxfuse. A good fuse compatibility test is
building tup tool [4] and run its tests. When I checked it with macfuse it
failed, I do not know what is the situation with osxfuse.

[1] http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystemsand
much more
[2] http://osdir.com/ml/macfuse/2011-05/msg00032.html
[3] http://fuse.sourceforge.net/
[4] https://trac.macports.org/browser/trunk/dports/devel/tup/Portfile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20111228/7b157a56/attachment.html>