Detecting that OSXFUSE is installed

[Alejandro Exojo]

Hi.

Is there some reliable way to detect wether OSXFUSE is installed? I've thought of detecting wether there is a /dev/osxfuse0 device, since I suppose the first thing fuse_main (or fuse_mount etc.) will do is try to open it, but I'd like to know if there is a better way.

I'm trying to follow the advice Benjamin has given in the list to distribute OSXFUSE with the application: detect on startup if the OSXFUSE is there, and if not, run the installer from a package in the application bundle.

Thank you.

[Benjamin Fleischer]

Hi Alejandro,

Checking for /dev/osxfuse0 to determine if osxfuse is installed will not work. The device is created by the FUSE kernel extension. But the kernel extension will not be loaded until the first FUSE volume is mounted. Its a chicken-and-egg situation.

You could check for libosxfuse or the Objective-C framework instead, depending on which library you are using for your file system.

Regards,

Benjamin

--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alejandro Exojo]

On 24 September 2015 at 22:16, Benjamin Fleischer <fle...@gmail.com> wrote:

Checking for /dev/osxfuse0 to determine if osxfuse is installed will not work. The device is created by the FUSE kernel extension. But the kernel extension will not be loaded until the first FUSE volume is mounted. Its a chicken-and-egg situation.

I see. That explains why I've seen some delay between installation time and it appearing.

 

You could check for libosxfuse or the Objective-C framework instead, depending on which library you are using for your file system.

Do you mean on disk the same way, right? I bundle the libosxfuse library in the application. I thought of checking the presence of /Library/Filesystems/osxfusefs.fs. How would that work if the user has installed in a different location, or that can't happen?

Thank you!

[Benjamin Fleischer]

You could check for libosxfuse or the Objective-C framework instead, depending on which library you are using for your file system.

Do you mean on disk the same way, right? I bundle the libosxfuse library in the application. I thought of checking the presence of /Library/Filesystems/osxfusefs.fs. How would that work if the user has installed in a different location, or that can't happen?

You should never bundle libosxfuse with your app. Please understand that libosxfuse and the FUSE kernel extension will only work together if both are from the same osxfuse release. This means, if you bundle libosxfuse 2.8.0 with your app and the user updates the kernel extension to version 2.8.1 your app will break! Your file system will no longer mount.

You are not the first developer trying to bundle libosxfuse with an app. But honestly, I do not get why anybody would want to do this. libosxfuse is by definition a shared library. It is an integral part of osxfuse. By bundling libosxfuse with your app you are basically ripping osxfuse apart. This will break with the next osxfuse update and leads to a bad user experience.

Regards,

Benjamin

[Alejandro Exojo]

On 27 September 2015 at 22:45, Benjamin Fleischer <fle...@gmail.com> wrote:

You should never bundle libosxfuse with your app. Please understand that libosxfuse and the FUSE kernel extension will only work together if both are from the same osxfuse release. This means, if you bundle libosxfuse 2.8.0 with your app and the user updates the kernel extension to version 2.8.1 your app will break! Your file system will no longer mount.

You are not the first developer trying to bundle libosxfuse with an app. But honestly, I do not get why anybody would want to do this. libosxfuse is by definition a shared library. It is an integral part of osxfuse. By bundling libosxfuse with your app you are basically ripping osxfuse apart. This will break with the next osxfuse update and leads to a bad user experience.

Thanks for the explanation, Benjamin. My experience on Mac is to bundle the libraries I'm using because those are not on the system, so I simply have to ship them, and I can't trust others to have them at the proper version and in a binary compatible way.

I understand the trouble, and I certainly will consider unbundling libosxfuse, but I really don't see a good solution at all. If the user upgrades/downgrades/removes libosxfuse and is in a binary incompatible way, the application will completely fail to start. I can show no error message with an explanation to the user, or try to diagnose the problem.

[Sam Moffatt]

I would suggest having your file system binary distinct from your main app so that it can run and be started as a separate process. I'd suggest that quitting your app might result in potential corruption due to someone force quitting the app thinking it's hung when realistically they still have an open file handle to it and it can't gracefully terminate itself.

Once you do this then your parent app can detect if OSXFUSE is installed, provide instructions on how to install it and then you can continue on your way. I'd ask that you make it clear you're using OSXFUSE so that we don't have to play the "what is OSXFUSE and how did it get onto my computer anyway" game with your users.

Thanks in advance :)

Cheers,

Sam

Sam Moffatt
http://pasamio.id.au

--

[Alejandro Exojo]

On 28 September 2015 at 09:01, Sam Moffatt <pas...@gmail.com> wrote:

I would suggest having your file system binary distinct from your main app so that it can run and be started as a separate process. I'd suggest that quitting your app might result in potential corruption due to someone force quitting the app thinking it's hung when realistically they still have an open file handle to it and it can't gracefully terminate itself.

Yes, using a separate process for file system business seems the only way. I started the application on Windows with Dokan, and there making the app link against the library and closing it with opened file handles works perfectly well.

Still, I'm not 100% sure that running a separate process for OSXFUSE would be able to distinguish a crash of the file system because an incompatible library or a mistake in the application, for example. Plus other lifetime issues, like the open file handle you mention. But I suppose is the best that can be done.

 

Once you do this then your parent app can detect if OSXFUSE is installed, provide instructions on how to install it and then you can continue on your way. I'd ask that you make it clear you're using OSXFUSE so that we don't have to play the "what is OSXFUSE and how did it get onto my computer anyway" game with your users.

Yes, I tried to explain to the client that it was important to let the users understand what was being installed in the computer. But of course the client and the users want to see it as an implementation detail that they should not be aware of.

I'm trying to find the best compromise for everyone. :)

Thank you both again.

[John Grigutis]

FWIW, you can check for the presence of OSXFUSE during installation if you use an installer (man productbuild). Here's a sample def.plist:

<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
     <key>bundle</key>
     <array>
         <dict>
             <key>id</key>
             <string>com.github.osxfuse.framework</string>
             <key>path</key>
             <string>/Library/Frameworks/OSXFUSE.framework/</string>
             <key>CFBundleShortVersionString</key>
             <string>2.7.5</string>
             <key>search</key>
             <false/>
         </dict>
     </array>
 </dict>
 </plist>

Just build the installer like so:

productbuild --product def.plist --component build/Release/Sample.app /Applications Product.pkg

If OSXFUSE is not found, the installer will not proceed and display's our failure message from InfoPlist.strings:

"RequiredBundlesDescription" = "The required version of OSXFUSE is not installed. Please install or update OSXFUSE: http://osxfuse.github.io/.";

You can also do this in a distribution file for more complex situations:

Distribution XML Reference

-- 

John

[Alejandro Exojo]

Hi. I've followed the approach of splitting the application so a GUI
process can check for OSXFUSE, and display a message and launch the
installer if not.

I have a couple of followup questions, though:

On 27 September 2015 at 22:45, Benjamin Fleischer <fle...@gmail.com> wrote:

> You should never bundle libosxfuse with your app. Please understand that
> libosxfuse and the FUSE kernel extension will only work together if both are
> from the same osxfuse release. This means, if you bundle libosxfuse 2.8.0
> with your app and the user updates the kernel extension to version 2.8.1
> your app will break! Your file system will no longer mount.

I understand the incompatibility between library and kernel extension
now, but what about binary compatibility of library and application?
I'm speaking about the C library only. From what I've seen, the API
hasn't changed in ways that change the ABI, so it looks good, but to
confirm. :)

> You are not the first developer trying to bundle libosxfuse with an app. But
> honestly, I do not get why anybody would want to do this. libosxfuse is by
> definition a shared library. It is an integral part of osxfuse. By bundling
> libosxfuse with your app you are basically ripping osxfuse apart. This will
> break with the next osxfuse update and leads to a bad user experience.

I'm following this advice, and try to make this the most user friendly
possible to install OSXFUSE. The customer ask to reduce the prompts to
the minimum, though. The advice given in the mailinglist to have a
silent installation is to run 'sudo installer -applyChoiceChangeXML
...' (1). Is there some way to reduce the choices in the GUI
installer?

Since I can't find one way, I've read also in the archives about
repackaging the OSXFUSE installer (2). The advice is not to do it, but
can't it be done in any way? I'll be OK if I just package the >10.9
part, and only the OSXFUSE library/framework (no need for MacFUSE for
example). If I can repackage OSXFUSE in a way that the initial install
is simpler, and doesn't break other installations, that would be
great.

I've started looking into that, but the build system is pretty
sophisticated (very well structured shell scripting, BTW!).

Thank you!

(1) https://groups.google.com/d/msg/osxfuse-group/rfNiamwPLMo/9vjesC3U29IJ
(2) https://groups.google.com/forum/#!searchin/osxfuse-group/installer/osxfuse-group/vy5jN5rtwZU/cQD7S-JG3kUJ

[Master Luu]

I solved same problem. I bundle  my app with osxfuse library. So my app will conflict with other app using osxfuse lib. Then, I edit some code in Osxfuse to change resources was install by Osxfuse -> It create a new file system don't using "osxfuse" name.  It works fine. So I don't care my app will conflict with other app and bug was occur when Osxfuse update new version.

Thank for reading. 

[arritje nof]

Am i possibly missing something here?

I'm surprised to see that there's been no mention at all of what i would find the most logical answer to the initial question "Is there some reliable way to detect wether OSXFUSE is installed?".

I would think the first place to look for evidence of the presence of OSXFuse on a given system, would be to see if it was actually installed;

Meaning: check the receipts database for traces of osxfuse, e.g. using pkgutil:

$ pkgutil --pkgs | grep -i osxfuse
com.github.osxfuse.pkg.Core

This pkg-ID can then be used to get all the files that were installed as part of that package:

$ > pkgutil --files com.github.osxfuse.pkg.Core
Library
Library/Filesystems
Library/Filesystems/osxfusefs.fs
...

But as i said, i might be missing the point here.

kind regards,

arjen

[Alejandro Exojo]

On 13 January 2016 at 21:18, arritje nof <arritjepa...@gmail.com> wrote:
> I would think the first place to look for evidence of the presence of
> OSXFuse on a given system, would be to see if it was actually installed;
> Meaning: check the receipts database for traces of osxfuse, e.g. using
> pkgutil:
>
> $ pkgutil --pkgs | grep -i osxfuse
> com.github.osxfuse.pkg.Core
>
>
> This pkg-ID can then be used to get all the files that were installed as
> part of that package:
>
>
> $ > pkgutil --files com.github.osxfuse.pkg.Core
> Library
> Library/Filesystems
> Library/Filesystems/osxfusefs.fs
> ...
>
> But as i said, i might be missing the point here.

What I understood of the PKG system, is that you can get things
installed, but not uninstalled, and that users might uninstall things
manually. For PKG files that provide applications, this might be a
very normal procedure. So I don't think this is a reliable way. :(

[Alejandro Exojo]

Thank you for your reply.

On 13 January 2016 at 10:54, Master Luu <luua...@gmail.com> wrote:
> I solved same problem. I bundle my app with osxfuse library. So my app will
> conflict with other app using osxfuse lib.

I don't understand this. If you add the library in your application
bundle, there is no conflict with other applications. That's the point
of application bundles.

> Then, I edit some code in Osxfuse
> to change resources was install by Osxfuse -> It create a new file system
> don't using "osxfuse" name. It works fine. So I don't care my app will
> conflict with other app and bug was occur when Osxfuse update new version.

You change code in OSXFUSE and compile it? Or you change some
configuration only, without recompiling?

How do you make it not use the "osxfuse" name? I think that if you
rename, you will need to do many renames (kernel driver, file system,
library paths, etc.).

[Ritik Malhotra]

Also wondering the same thing here. Were you able to figure this out? 

[Alejandro Exojo]

On 29 February 2016 at 21:01, Ritik Malhotra <ritikm...@gmail.com> wrote:

> Then, I edit some code in Osxfuse
> to change resources was install by Osxfuse -> It create a new file system
> don't using "osxfuse" name.  It works fine. So I don't care my app will
> conflict with other app and bug was occur when Osxfuse update new version.

You change code in OSXFUSE and compile it? Or you change some
configuration only, without recompiling?

How do you make it not use the "osxfuse" name? I think that if you
rename, you will need to do many renames (kernel driver, file system,
library paths, etc.).

Also wondering the same thing here. Were you able to figure this out? 

 

No. I don't even attempted it. I know too little about the low level parts to just make an educated guess. I would not mind if there is a sanctioned process for rebuilding OSXFUSE as a "branded" filesystem that developers can install and control a bit more easily. Right now I just try what I said at the beginning: find if libosxfuse is there (as Benjamin said), and if so, my helper process is supposed to run safely.

[Paul Eipper]

Would there be an overhead of running many "branded" osxfuse kernel
extensions in parallel for each app? (assuming it even works?)

--
Paul Eipper