Unable to mount sparse disk image off of SSHFS mount

[GoogleCodeExporter]

What steps will reproduce the problem?
1. On OS X 10.5.1 Leopard, install MacFUSE-Core-10.5-1.1.1. 
2. Run command...

mkdir /Volumes/temp & sshfs rubin110@jester:/media/brown/ /Volumes/temp

3. Once remote volume is mounted, browse to an existing spars disk image
and attempt to mount it by double clicking the file under the Finder.

What is the expected output?

Sparse disk image mounts.

What do you see instead?

Finder pops up with an error, "no mountable file systems."

What version of the product are you using? On what operating system?

OS X 10.5.1 Leopard, MacFUSE-Core-10.5-1.1.1

Please provide any additional information below.

I initially saw this after attempting to mount the sparse disk image for my
Aperture backups, which is roughly 20 gigs. I was able to do this before
under Tiger with the previous version of MacFUSE just fine.

Some other things I tested out...

- I can mount just fine through SMB, though I'm not too sure if it'll be
cool with a 2+ gig file flying between machines.
- I created a new sparse disk image locally, then attempted to copy over to
the SSHFS mount via Finder, works fine.
- Am able to mount the file copied in the previous bullet just fine via SMB
but not SSHFS.
- Through both SSHFS and SMB, the file permissions are 700.
- Can mount DMGs just fine.

Original issue reported on code.google.com by RubinSta...@gmail.com on 21 Nov 2007 at 4:43

[GoogleCodeExporter]

Disk image mounting has changed in certain ways (some of them subtle) in 
Leopard. One
difference is in the use of a user-space helper process for attachment, as 
opposed to
handling the image directly in the kernel through the IOHDIXController kernel
extension. The entire disk image mounting paraphernalia is closed source, so 
it's
hard to debug, analyze, understand.

Try forcing the sparse image to be handled in-kernel and see if that works. 
Here's how:

If you try mounting, say, /Volumes/temp/foo.sparseimage from the command line 
through
the "open" command, I'm assuming you'll run into the error that you mention.

$ cd /Volumes/temp/
$ open foo.sparseimage
# error?

You can use the com_apple_hdid_kernel environment variable to force in-kernel 
attachment.

$ cd /Volumes/temp/
$ com_apple_hdid_kernel=1 open foo.sparseimage
# does it work now?

Original comment by si...@gmail.com on 21 Nov 2007 at 8:00

[GoogleCodeExporter]

Yup, that totally worked. Is there any way to force Finder/Path Finder to mount 
in
this fashion?

Totally not a defect anymore, thanks!

Original comment by RubinSta...@gmail.com on 21 Nov 2007 at 8:47

[GoogleCodeExporter]

> Totally not a defect anymore, thanks!

It is, actually, something that requires a fix on the MacFUSE kernel side. You
shouldn't have to force Finder etc. and it should "just work." If you want to 
help me
test the fix, try the following:

1. Mount with and additional mount-time argument "-oblocksize=512". See if it 
works
without any magic environment variables. This isn't the real fix though--you
shouldn't have to force block size to 512.

2. If you are willing and able to compile MacFUSE from source (it's pretty
straightforward -- see the HOWTO), you can try the real fix to see if my
understanding of your issue is correct. In 
macfuse/core/10.5/fusefs/fuse_vfsops.c,
add the following lines after line 437 (immediately before the line that says
"vfs_setfsprivate(mp, data);":

    {
        struct vfsioattr ioattr;

        vfs_ioattr(mp, &ioattr);
        ioattr.io_devblocksize = data->blocksize;
        vfs_setioattr(mp, &ioattr);
    }

Original comment by si...@gmail.com on 22 Nov 2007 at 3:20

[GoogleCodeExporter]

Fixed in the source tree.

Original comment by si...@gmail.com on 22 Nov 2007 at 7:18

• Changed state: Fixed