Document based app hangs when opening file in VFS

[mixtly]

I have a FUSE-based virtual disk app which shows contents of remote server document system.

Every not-downloaded file shown in VFS has an extension .remotefile.

My goal was that when user opens a file (ie in Finder), to open it with my app which would then trigger file download and upon successful download rename the file so that it loses the .remotefile extension and open the file in the proper app ie by calling [NSWorkspace openFile:]

However, if I open a file which is in VFS, then the whole app hangs as if some fuse-internal deadlock happens. After 30 seconds disk gets unmounted because of fuse-timeout. It somehow seems related to the fact that file that I want to open is in VFS.

Ie, if I try to open a file on my desktop with the same extension then [AppDelegate openFile] is regularly called.

Expected:

when I open a file in VFS with registered file-extension (.remotefile), my app should get [AppDelegate openFile:] callback.

Actual:

App hangs when opening a file in VFS.

It does work properly when opening a file outside of VFS (ie file on Desktop).

Does anyone have a hint as to what could be the issue here? I also tried implementing simple - (NSData*) contentsAtPath:(NSString*)path fuse callback where I always return some content just to see if it's something related to file not-having any downloaded content yet, but the behavior stays the same.

[Sam Moffatt]

This might be a strange question but have you tried running your filesystem in single threaded mode with debug logging on to reproduce the issue? It should tell you exactly what operations are being run in what order in a way that isn't completely messed up. It feels like perhaps something else is being called first (perhaps some sort of stat call) that is causing issues.

One other thought is that for consistency's sake, you need to handle the old path regardless because the app is opening up a given file, even if you try to move it from underneath of it, it might still try to write back to the original file name. It could be that an earlier call is triggering the background download already and is blocking a request somewhere.

Cheers,

Sam Moffatt
http://pasamio.id.au

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/osxfuse-group/bb073531-3781-4840-a0ad-1e24f7c6d3a7%40googlegroups.com.

[mixtly]

I managed to solve the issue (I think), or at least find the root cause.

The thing is that on every fuse callback (ie openFile, contentsAtPath, attributesOfItemAtPath,...), I do dispatch_sync to main queue where CoreData handling is done. The result is then returned on the fuse-thread. Example:

- (BOOL) createDirectoryAtPath:(NSString*)path ...

{

    __block BOOL ret = NO;

    dispatch_sync(dispatch_get_main_queue(), ^{

        // create new folder in database

    });

    return ret;

}

Now, since AppDelegate.openFile(String filename) is called on the main queue, somehow it causes deadlocks with the FUSE thread.

Deadlock causes were linked with fuse callbacks valueOfExtendedAttribute and attributesOfItemAtPath. I managed to solve that by handling these callbacks in somewhat special way so that when file is being opened no jumping to main queue is necessary.

Interesting thing: before these fixes I used to see deadlocks which would last for exactly 2.5 seconds! I'm not sure what then unblocks them but in the meantime I managed to solve the issue.

To unsubscribe from this group and stop receiving emails from it, send an email to osxfus...@googlegroups.com.

[Benjamin Fleischer]

Using your app's main queue for file system operations is not a good choice. It would be better using a dedicated queue or thread for that. The main queue is needed to handle app events, like processing the openFile: callback in your case. All file system operations originating from the main queue will deadlock your file system. Please keep in mind that unforeseen file system operations might be triggered by Apple Frameworks.

As a general rule a FUSE file system should never trigger file systems operations on the FUSE volume during a FUSE callback. This will almost certainly cause deadlocks.

Best regards,

Benjamin

To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osxfuse-group/2aa6f442-055c-466c-adba-e52e4d3a3d42%40googlegroups.com.

[mixtly]

Thanks Benjamin,

I'll look into refactoring that component so that FUSE callbacks don't perform any work on the main queue. Right now, we're not experiencing issues with that approach (3 years app), however I see the problem.

Best regards,
Marko

To view this discussion on the web visit https://groups.google.com/d/msgid/osxfuse-group/2aa6f442-055c-466c-adba-e52e4d3a3d42%40googlegroups.com.