Difference between Objective-C and C APIs - C loopback sample doesn't work, Obj-C one does

[cctv...@gmail.com]

Mavericks release introduced a really weird regression to the OSXFUSE-based filesystem I've wrote - MS Word documents open as blank ones. Here's my post on SO: http://stackoverflow.com/questions/20753080/osxfuse-what-exactly-does-the-local-mount-option-mean .

Trying to isolate the issue, I found out that the loopback sample, which comes with OSXFUSE, also exhibits this defect - MS Word documents open as blank, although the data is, apparently, there - Quicklook correctly displays the preview, and if you copy a file to a native filesystem, it opens correctly from there. Mounting filesystem with the "local" option fixes the issue (but I cannot use it because of other regressions it introduces).

Strangely, Objective-C loopback sample seems to be working OK.

I'd greatly appreciate any help with this.

Vladimir

[Benjamin Fleischer]

There is a known issue when using Microsoft Office on Mavericks to open documents on a FUSE volume that was mounted while Google Chrome was running. Both versions of loopback (C and Objective-C) are affected. There is at least one additional file system I’m aware of that exhibits the same problem.

Repro steps:

1. Start Google Chrome

2. Mount FUSE file system (without local flag)

3. Try to open Office document with Microsoft Office

4. Document does not open correctly

If Chrome is not running while mounting the FUSE volume the Office document should open correctly.

So far I have not found any bugs in osxfuse that might explain this behavior. The odd thing is that the files are not corrupted or empty. After copying the files to another volume they open just fine. Using LibreOffice to open the file on the FUSE volume works, too.

Chrome and Office seem to be based on the Carbon framework (which is deprecated since Mountain Lion). I believe the issue is somehow related to Carbon since non-Carbon apps do not seem to be affected. Every time a volume is mounted Chrome queries the volume’s capabilities and attributes (and maybe more). As far as I can tell all these file system operations return successful without any errors. But from this point on Office will fail to open documents.

In my opinion the two most likely reasons for this are:

1. osxfuse might break the VFS file system contract on Mavericks. I’ve been looking into this for some time now but I have not found any clues supporting this.

2. There might be a bug in the Carbon/CarbonCore framework. The odd thing is that there are no issues when using the stock network file systems afp or smb.  

Mounting filesystem with the "local" option fixes the issue (but I cannot use it because of other regressions it introduces).

So far "local" is the only workaround (for the Google Chrome issue) I’m aware of. But using local for network file systems is not recommended.

Strangely, Objective-C loopback sample seems to be working OK.

OSXFUSE.framework is just a wrapper for libosxfuse. If you are using Chrome, could you check again if it keeps working for you while Chrome is running? 

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/groups/opt_out.

[Robert Freudenreich]

Possible "workarounds" for this problem seem to be (as of OSXFUSE 2.6.2):

1. Use the "local" mount option (which might introduce other problems and is generally not recommended to use)
2. Do not use the "volname" mount option. Benjamin found out that the problem seems only to occur when the "volname" mount option is used. If no custom volume name is set, the problem seems not to occur and Excel/Word/etc. files open just fine - regardless whether Google Chrome was running at mount time.

--Robert

[cctv...@gmail.com]

Thanks!

It does indeed look like it's Chrome that messes things up. It appears that running it at the moment of mounting a filesystem matters, once mounted, closing/reopening Chrome doesn't seem to affect the issue.

Strangely, Objective-C loopback sample seems to be working OK.

OSXFUSE.framework is just a wrapper for libosxfuse. If you are using Chrome, could you check again if it keeps working for you while Chrome is running? 

Obj-C  sample does not _always_ work, but at least _sometimes_  it works, while C sample never works for me. As to when Obj-C sample works - hard to tell, couldn't find any meaningful pattern. It _seems_ running C sample messes things up even for Obj-C sample, e.g.:

1. Run Obj-C LoopbackFS, observe it opens Word documents correctly;
2. run C loopback sample, it opens a document as blank;
3. run Obj-C sample again and observe it opens it as blank as well.

However, I cannot say this is a reliable pattern, seems to be intermittent.

If Obj-C API is just a wrapper - well, don't really know what matters. May be, it has different defaults for options, etc? And sample programs themselves are different, may be that matters.

Vladimir

[cctv...@gmail.com]

Possible "workarounds" for this problem seem to be (as of OSXFUSE 2.6.2):

1. Use the "local" mount option (which might introduce other problems and is generally not recommended to use)
2. Do not use the "volname" mount option. Benjamin found out that the problem seems only to occur when the "volname" mount option is used. If no custom volume name is set, the problem seems not to occur and Excel/Word/etc. files open just fine - regardless whether Google Chrome was running at mount time.

Hmm, commented out setting "volname", still see the same issue. However, I noticed another thing: running Chrome also messes up "volname" option as well. I.e., whenever Chrome is running while filesystem is mounted, I get a "blank Word document" issue and volume option seems to be ignored. When Chrome is not running when filesystem is mounted - Word documents open correctly and volume name is set as expected.

Vladimir

[craigc...@gmail.com]

Interesting issue here with Chrome and osxfuse. I can reproduce the error consistently - when I sshfs mount with chrome open, I cannot open a word/excel document stored on the mounted drive (using Office for Mac 2011). When chrome is not running, I CAN open a word/excel file, but I cannot make changes to it, citing that it may be out of disk space (I know this is not an issue). So, any clues as to why I cannot save a word/excel file? Other files/apps seem to work just fine, for instance emacs. Thoughts on a fix?

Thanks,

Craig