macfuse

Thu Dec 29 07:33:19 PST 2011

Hi,

Thanks for the info. It's clear you have a better understanding than i do, I was just following things on the lists, as a user of MacFuse, and yes I did get the feeling somehow that osxfuse was better supported/advanced than osxfuse, but maybe that was just because I followed things mostly from the MacFuse / OSXfuse mailing lists ….

If fuse4x is aiming to be more compatible (i.e. 100%) with upstream fuse, unlike osxfuse, then I agree this is probably worth giving up ABI compatibility with macfuse for. Cleaning up crude from code is always a good idea as well …

I just throw the idea in to see why fuse4x was being discussed, and now I know why...

cheers Chris

On 29 Dec 2011, at 6:17am, Anatol Pomozov wrote:

> 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=FileSystems and 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
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20111229/417f7712/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2966 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20111229/417f7712/attachment.bin>