I have crash logs to send your way if you need help. I am a systems integrator and can assist with troubleshooting but I can't do any developmental work or comment beyond logs and crash reports. I have seen many odd crashes (15-20) usuallu doing simple things like opening Finder windows.
That said my copy of MacFUSE 2.0.3 was installed by Parallels Desktop VM software (version 5.x), so I end up with it due to certain dependencies within my VM setup. I am on Google Wave and GMail - jbunston -at- gmail.com. Regards, JB On Sep 28, 5:49 pm, Amit Singh <[email protected]> wrote: > Since I've been dormant for a while from this group's standpoint, > several questions and speculations have piled up regarding MacFUSE's > Snow Leopard status. I'm answering some questions in this post. Please > read the whole thing carefully before jumping to further conclusions. > > * What have I been up to? > > I've been busy with things other than MacFUSE. > > * What has the MacFUSE team been up to? > > The myth of the MacFUSE team has become rather annoying. There is no > MacFUSE "team" and there never has been one. The MacFUSE distribution > has the following components: > > 1. The command-line software updater/installer (autoinstaller) > 2. The preference pane (MacFUSE.prefPane) > 3. The Objective-C framework (MacFUSE.framework) > 4. Everything else (kernel extension, user libraries, helper tools) > > Greg Miller and Dave MacLachlan wrote components 1 and 2, > respectively, as *one time* favors to the project. > > Ted Bonkenburg wrote component 3. > > I take care of the rest. Since component 4 constitutes the core of the > project and is the part that needs work (or the most work) when Mac OS > X changes, if I have other higher priority things to do, things can > stall with MacFUSE. Please realize that I have a full-time job (and > MacFUSE is not it), a family, and several other pursuits besides > MacFUSE. Also, I'm not even working on Mac stuff any more in my > official job. > > I'll tell you about the "MacFUSE QA team" some other time. > > * What's the deal with MacFUSE on Snow Leopard? > > As far as I know, MacFUSE is fine on Snow Leopard as long as you run > the 32-bit kernel. In particular, you can choose to write either a 32- > bit or a 64-bit MacFUSE-based application because the 64-bit MacFUSE > libraries should be fine. > > Under the 64-bit kernel, MacFUSE (at least the official release) > shouldn't cause any problems because the kernel extension wouldn't > even load. > > The 2008 December release did work with the 64-bit kernel. It was > "experimental" because Snow Leopard itself was experimental then. > Since then, things have changed with OS X and I've not had the time or > the need to fix MacFUSE. I'll get to the 64-bit kernel part if/when I > can. > > If you are a file system developer, there may be some other things to > know about Snow Leopard and MacFUSE. One thing is about the larger > stat structure on Snow Leopard. I think somebody on this forum posted > about this--please look for that post. In short, if you compiled a > previously working file system on Snow Leopard and it stops working > completely (you get I/O errors even when trying to list the root > directory of your file system), you've run into the stat structure > issue. The MacFUSE libraries are compiled with Leopard compatibility, > which means the smaller stat structure. The "ino64" version of the > MacFUSE library *is* compiled with the larger stat structure. If > you're going to run your file system binary on both Leopard and Snow > Leopard, then you'll be compiling it with Leopard compatibility anyway > (-mmacosx-version-min=10.5). Otherwise, use the ino64 library. > > * What about the reports of MacFUSE being "known to crash Snow > Leopard"? > > Nobody has reported any crashes to me. I've only read some third-hand > accounts in some threads on this forum. One of the following must be > happening: > > - People don't know what they are talking about. > - People are running a custom-compiled MacFUSE under a 64-bit kernel. > > Usually (barring certain types of memory corruption), a panic log will > tell you the name of the kernel extension (if an extension was indeed > involved) that caused the crash. > > * Custom-compiled MacFUSE under a 64-bit kernel? > > I noticed that some of you are compiling/distributing a MacFUSE kernel > extension for the 64-bit kernel. Simply recompiling it is not going to > work--a bunch of non-trivial work is needed. If you simply recompile > it (by commenting out the #ifdef guards, as I believe folks did), > it'll load under K64 and might even appear to work. But at best, > you'll get a kernel panic, and at worst, you'll get data corruption. > > You can "test" this yourself under K64. Use the custom-compiled > version to mount some file system with a bunch of files. Then, from > multiple terminal windows, cause some continuous file activity, say, > some 'find' loops. You should get a kernel panic in no time. > > Unless you are a kernel developer who wants to "hack" on MacFUSE, I > wouldn't advise you recompile MacFUSE, specially the kernel extension. > Even if you do, distributing it is likely to cause pain and confusion. > > Amit --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
