Overlay mount to the same source directory

[sinlam]

Hi, currently I am investigating to use Fuse4x for my Mac OS X file system encryption project. I would like to know whether it is possible to do overlay mount on top of existing source directory such as

> fuse4x /Users/user/Documents /Users/user/Documents

I use Fuse4x version 0.9.0 on Mac OS X 10.7.3 64 bits but I am unsuccessful to do this overlay mount. I know that the source path is unavailable after the overlay mount, so I have tried to create a global namespace using bindfs (MacPort) and uses 'fchdir' to change to source directory before calling Fuse_main function. Both approaches also hangs the Mac OS and Fuse4x terminated itself after a few minutes. How can I access source directory after the overlay mount?

If anyone has used Fuse4x to do overlay mount in Mac OS X, please let me know how to do this. Thanks for any information!

Regards,
Sin Lam

[sinlam]

Any suggestion is appreciated...

[Anatol Pomozov]

Hi

On Tue, May 8, 2012 at 6:40 PM, sinlam <slt...@gmail.com> wrote:

Hi, currently I am investigating to use Fuse4x for my Mac OS X file system encryption project. I would like to know whether it is possible to do overlay mount on top of existing source directory such as  

> fuse4x /Users/user/Documents /Users/user/Documents

I use Fuse4x version 0.9.0 on Mac OS X 10.7.3 64 bits but I am unsuccessful to do this overlay mount. I know that the source path is unavailable after the overlay mount, so I have tried to create a global namespace using bindfs (MacPort) and uses 'fchdir' to change to source directory before calling Fuse_main function. Both approaches also hangs the Mac OS and Fuse4x terminated itself after a few minutes. How can I access source directory after the overlay mount?

 

I do not think it is possible. Once you mount filesystem on a mountpoint the previous path is hidden. You cannot access that old mountpont by *path*. When I say "by path" I assume that your filesystem uses high-level fuse API that returns full file-path you access, and then you try to access the same file recursively and it leads to deadlock.

If you could provide more info what you are trying to do then I might suggest something more useful.

One trick that comes to my mind is to open a file descriptor to the old mountpont (before mounting fuse4x fs) and then use *at() functions to get access to *old* files/vnodes. It might work because the open file descriptor points to hidden directory (mount syscall does not change it) and it only needs to resolve path relative to the old moutpont (thus path resolving function does not cross the mount-point border). See a openat() POSIX function, but I am not sure if XNU implements it.

If anyone has used Fuse4x to do overlay mount in Mac OS X, please let me know how to do this. Thanks for any information!

You might want to ask this question in upstream project as well [1] as it seems broader than fuse4x.

[1] https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Anatol Pomozov]

Hi

Oops I see that in the private email you pointed to http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#If_a_filesystem_is_mounted_over_a_directory.2C_how_can_I_access_the_old_contents.3F that suggests a solution for your issue. I expect that "fchdir(save_dir)" should work with fuse4x.

When your filesystem hangs? during fchdir(save_dir) in init()? If so it means for some reason is resolved to fuse4x directory and causes recursion/deadlock.

[sinlam]

Hi,
  Thanks for the information!

I do not think it is possible. Once you mount filesystem on a mountpoint the previous path is hidden. You cannot access that old mountpont by *path*. When I say "by path" I assume that your filesystem uses high-level fuse API that returns full file-path you access, and then you try to access the same file recursively and it leads to deadlock.

If you could provide more info what you are trying to do then I might suggest something more useful.

I would like to implement encrypted file system that transparently encrypt & decrypt /Users/<user> directory, /tmp and other newly mounted drives (e.g. external HD or thumb drive or network drive). I hope to do the overlay mount so that I don't need to create a new mount point for each directory or drives that I want to protect. When I create a new mountpoint, an application may still using the old path and I don't want the application to access the old path. That is why overlay mount is important.
 

One trick that comes to my mind is to open a file descriptor to the old mountpont (before mounting fuse4x fs) and then use *at() functions to get access to *old* files/vnodes. It might work because the open file descriptor points to hidden directory (mount syscall does not change it) and it only needs to resolve path relative to the old moutpont (thus path resolving function does not cross the mount-point border). See a openat() POSIX function, but I am not sure if XNU implements it.

I consider that but MAC OS X does not have at() functions, and it also does not have fdopendir(). There is a discussion about this issue in http://sourceforge.net/mailarchive/forum.php?thread_name=87tykhcd6l.fsf%40frosties.localdomain&forum_name=fuse-devel
I follow the discussion but also unsuccessful, due to no fdopendir().
 

[sinlam]

Oops I see that in the private email you pointed to http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#If_a_filesystem_is_mounted_over_a_directory.2C_how_can_I_access_the_old_contents.3F that suggests a solution for your issue. I expect that "fchdir(save_dir)" should work with fuse4x.

When your filesystem hangs? during fchdir(save_dir) in init()? If so it means for some reason is resolved to fuse4x directory and causes recursion/deadlock.

When I called change dir to old path before calling fuse_main(), it does not hang immediately. Inside xmp_statfs function, I change from fullpath to relative path.
Then I notice xmp_statfs is called more 2500 times and OS crashed after a while. Let me know if you have any information how to solve this problem.

Thanks,
Sin Lam

[Anatol Pomozov]

Hi

On Fri, May 18, 2012 at 1:49 AM, sinlam <slt...@gmail.com> wrote:

Oops I see that in the private email you pointed to http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#If_a_filesystem_is_mounted_over_a_directory.2C_how_can_I_access_the_old_contents.3F that suggests a solution for your issue. I expect that "fchdir(save_dir)" should work with fuse4x.

When your filesystem hangs? during fchdir(save_dir) in init()? If so it means for some reason is resolved to fuse4x directory and causes recursion/deadlock.

When I called change dir to old path before calling fuse_main(), it does not hang immediately. Inside xmp_statfs function, I change from fullpath to relative path.
Then I notice xmp_statfs is called more 2500 times

This is a known issue. Or better to say this is one of the "Carbon/Finder wisdoms".

Originally macfuse/fuse4x used "cache statfs data in userspace" option. This option is set in fuse4x kext. But this lead to a bug when Finder shows out-of-date volume size information. I've changed it to "do not cache statfs" but in this case Finder generates much more requests. If this is an issue for you you should cache this data in your filesystem.

 

and OS crashed after a while.

What is the crash stacktrace?

Does it mean that the deadlock issue (you mentioned in the initial message) has gone?

[sinlam]

On Tuesday, May 22, 2012 11:50:09 AM UTC+8, Anatol Pomozov wrote:

Hi

On Fri, May 18, 2012 at 1:49 AM, sinlam <slt...@gmail.com> wrote:

Oops I see that in the private email you pointed to http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#If_a_filesystem_is_mounted_over_a_directory.2C_how_can_I_access_the_old_contents.3F that suggests a solution for your issue. I expect that "fchdir(save_dir)" should work with fuse4x.

When your filesystem hangs? during fchdir(save_dir) in init()? If so it means for some reason is resolved to fuse4x directory and causes recursion/deadlock.

When I called change dir to old path before calling fuse_main(), it does not hang immediately. Inside xmp_statfs function, I change from fullpath to relative path.
Then I notice xmp_statfs is called more 2500 times

This is a known issue. Or better to say this is one of the "Carbon/Finder wisdoms".

Originally macfuse/fuse4x used "cache statfs data in userspace" option. This option is set in fuse4x kext. But this lead to a bug when Finder shows out-of-date volume size information. I've changed it to "do not cache statfs" but in this case Finder generates much more requests. If this is an issue for you you should cache this data in your filesystem.

 

May I know how can I cache statfs data in my file system? Any example code is appreciated.

 

and OS crashed after a while.

What is the crash stacktrace?

Does it mean that the deadlock issue (you mentioned in the initial message) has gone?

 

I revisited the problem by using existing sample source 'fusexmp_fh' without modification. After compilation, I use the following command to execute the sample:

>sudo ./fusexmp_fh /Users/user/Documents -d -omodules=subdir,subdir="/Users/user/Documents" -o default_permissions -oallow_other

 Note that /Users/user/Documents exist but it is empty. The debug output of fusexmp_fh contains the last few lines:

unique: 2554, opcode: STATFS (17), nodeid: 1, insize: 40
unique: 2555, opcode: STATFS (17), nodeid: 1, insize: 40
unique: 2556, opcode: STATFS (17), nodeid: 1, insize: 40
unique: 2557, opcode: STATFS (17), nodeid: 1, insize: 40
fuse: error creating thread: Resource temporarily unavailable
statfs /
statfs /
statfs /
statfs /
unique: 2558, opcode: STATFS (17), nodeid: 1, insize: 40
statfs /

After a few minutes, OS crashed and I am able to get the backtrace with the following output:

(gdb) bt
#0  0xffffff7f807fb19c in ?? ()
#1  0xffffff800032b4c8 in dn_times_locked (dnp=0x60, t1=0xffff0073746e656d,
    t2=0x0, t3=0xffffff8006c98800, just_changed_flags=111366528)
    at devfs_vnops.c:143
#2  0xffffff800031b4dd in do_journal_io (jnl=0xffffff8040253e00,
    offset=0xffffff8040253e40, data=0xffffff8040253e40,
    len=18446743524065104256, direction=1076182592) at vfs_journal.c:385
#3  0xffffff8000312aa6 in get_xattrinfo (xvp=0xffffff8040253eb0,
    setting=1076182704, ainfop=0xffffff8040253eb0, context=0xffffff8040253eb0)
    at vfs_xattr.c:2641
#4  0xffffff8000563b8a in soo_select (fp=0xffffff8040253e00, which=186654344,
    wql=0xffffff8006a35180, ctx=0xffffff8006a35180) at sys_socket.c:398
#5  0xffffff8000563d02 in soioctl (so=0x0, cmd=18446743524140392072,
    data=0xffffff8006a35180 "?Q?\006????\001", p=0x1) at sys_socket.c:249
#6  0xffffff80005cd61b in DKeyHas4Words ()

If the /Users/user/Documents contains some files, the system just hangs there (deadlock).
Please let me know if anything I can do. Thanks!