ObjC framework should avoid [NSFileManager defaultManager]

[ChrisJEChandler]

Hi All,

In GMUserFileSystem.m, around line 2438:

// Trigger initialization of NSFileManager. This is rather lame, but if we
// don't call directoryContents before we mount our FUSE filesystem and
// the filesystem uses NSFileManager we may deadlock. It seems that the
// NSFileManager class will do lazy init and will query all mounted
// filesystems. This leads to deadlock when we re-enter our mounted fuse fs.
// Once initialized it seems to work fine.
NSFileManager* fileManager = [NSFileManager defaultManager];

In the past, I created my own fork of MacFUSE.framework that used

      NSFileManager* fileManager = [[[NSFileManager alloc] init] autorelease];

instead, to avoid thread safety problems with my own code. As per the documentation: "In Mac OS X v 10.5 and later you should consider using [[NSFileManager alloc] init] rather than the singleton method defaultManager. Using [[NSFileManager alloc] init] instead, the resulting NSFileManager instance is thread safe."

Unfortunately I can't build all the platforms you support, so I don't want to want to modify your source tree.

Thank you for picking up where MacFUSE left off

Regards,
Chris

[bfleischer]

Hi Chris,

it sounds very reasonable. Thanks for the explanation and the patch.

Regards,
Benjamin

[duncanhume]

I have been wrestling with what seems to be this exact problem for the last few days!

When mounting the loopback example on a USB disk, every so often it deadlocks on the first attributesOfItemAtPath. So I'm hoping this will be the fix.

I have 2 questions..

I have not yet tried to build the OSXFUSE as I have not needed to, and quite frankly I'm lazy! Can you tell me please when your next binary release might me available with this fix?

Do you think this fix should also be used in the loopback? where the defaultManager is used extensively?

As Chris said, Thanks for OSXFUSE!

Duncan

[bfleischer]

When mounting the loopback example on a USB disk, every so often it deadlocks on the first attributesOfItemAtPath. So I'm hoping this will be the fix.

Could you provide more detailed instructions on how to reproduce this issue? Then I could try to reproduce it.

I have not yet tried to build the OSXFUSE as I have not needed to, and quite frankly I'm lazy! Can you tell me please when your next binary release might me available with this fix?

There are still two known issues that I would like to fix before releasing OSXFUSE 2.4.3. This may take two weeks or so. It's hard to give an exact estimate.

Do you think this fix should also be used in the loopback? where the defaultManager is used extensively?

To be honest I don't know much about the internal workings of NSFileManager. I'm aware of the fact that using the singleton [NSFileManager defaultManager] can cause issues in multi-threaded applications. If you could provide detailed instruction on how to reproduce your deadlocking issue I could try to track it down.