Follow symlins and mount their contents

[GoogleCodeExporter]

What steps will reproduce the problem?

Setup a directory with the following structure. Dir called TV and inside TV 
have subdirectories and inside those subdirectories have symlinks to 
directories that contain directories of rar files.

The symlinks appear when mounted but they are not actually mounted, they appear 
like symlinks to directories with rarfiles that aren't mounted.

rar2fs v1.17.2
FUSE library version: 2.9.2
fusermount version: 2.9.2
using FUSE kernel interface version 7.19

Linux GXT3 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux

Original issue reported on code.google.com by delf.eld...@gmail.com on 24 Jul 2013 at 4:14

[GoogleCodeExporter]

I will see what can be done. However, I really doubt that symlinks pointing 
outside of the mount point can not be resolved easily since it would break the 
file system path as presented by the kernel and to the application via FUSE 
user space library. 
Is that the case? Is the symlinks pointing to files outside your mount point 
root?

Original comment by hans.bec...@gmail.com on 24 Jul 2013 at 4:51

• Changed state: Accepted

[GoogleCodeExporter]

Just tried this myself and everything works as expected if the link target is 
located on the same file system level. Trying to link to something outside the 
currently mounted file system will fail. AFAIK this is expected as *no* file 
system (fuse or other) will resolve links across mounted file system 
boundaries. If you need to link to something outside your mount point (not 
below), creation of one (or more) rar2fs mount points covering also the link 
target might do the trick. Eg. this should/might work:

folder /a (mounted by rar2fs)
folder /b (mounted by rar2fs)

files inside a ?can? now link to files inside b

Original comment by hans.bec...@gmail.com on 24 Jul 2013 at 6:27

[GoogleCodeExporter]

Nope. That does not work. The problem is still that the link is targeting 
something outside current *mounted* file system boundary! The instance of 
rar2fs that perform the 'ls' like operation never gets called. Also, since the 
link target is actually pointing to the native file system directory, neither 
does the other instance of rar2fs! I tried to link between rar2fs mounts but 
that was not possible and only resulted in a error message from FUSE. I think 
you need to re-consider what your are trying to do or simply make sure all your 
files are covered by one and the same mount point. Should not be that hard to 
do.

Original comment by hans.bec...@gmail.com on 24 Jul 2013 at 6:54

[GoogleCodeExporter]

One solution that I found is working similar to symbolic links but works across 
different mounted filesystems is the bind mount.
Lets say you have three folders named f1, f2 and f3. If you have RAR 
files/folders in f1 and f3 your can create a folder in f1 that you bind mount 
to f3 (e.g mount --bind ../f3 f1/f3). Then if you mount rar2fs from f1 to f2 
files in f3 will also be expanded as expected from the f2 mount point.

Original comment by hans.bec...@gmail.com on 26 Jul 2013 at 11:13

• Changed state: WontFix

[GoogleCodeExporter]

More updates. Another solution I found working is this.
If there are eg. two different folders holding RAR archives, /a and /b, that 
are *both* mounted using rar2fs on a1 and b1 respectively:
Creating symbolic links from /a -> b1 works as expected when accessing files in 
a1.
You can not create symbolic links from /a -> /b since /b is not a rar2fs file 
system!
Those links will be resolved directly by the kernel and the user space library 
(and rar2fs) will never be notified.

Original comment by hans.bec...@gmail.com on 27 Jul 2013 at 4:05

[GoogleCodeExporter]

There is however currently one limitation in rar2fs. It does not implement the 
symlink() callback which means symbolic links cannot be created on a live 
rar2fs file system! I will add this functionality but it is not going to make 
much of a difference. The symbolic links can still be created before mounting. 
So it is more of a "convenience" function to support it.

Original comment by hans.bec...@gmail.com on 27 Jul 2013 at 4:09

[GoogleCodeExporter]

Confirmed by FUSE development support. This is not something a user space file 
system has any control over. See previous suggested alternatives instead.

On 2013-07-27 10:58, Kyle Lippincott wrote:
"Symlinks are essentially text files with a special handler.  You have no 
control over what the kernel does with the path referenced by the symlink.  The 
kernel sees a symlink pointing to "/usr/bin" and completely forgets about your 
filesystem being involved at all. 

Some of the confusion might come from the fact that many/most shells use an 
environment variable like PWD to keep track of what directory you typed in, but 
to the kernel and every executable you run, you're really in the target 
directory and the symlink is not involved at all.

So yes, it is expected that if your filesystem has a symlink that points to 
not-your-filesystem, then you will not see any actions on the target node."

The support for creating symbolic links on a live rar2fs file system has been 
added to trunk.

Case closed.

Original comment by hans.bec...@gmail.com on 28 Jul 2013 at 8:21