Follow symlinks and mount their contents

[hasse69]

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.eldkraft on 2013-07-24

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-24 16:51:11

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-24 18:27:49

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-24 18:54:06

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-26 11:13:24

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-27 16:05:59

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-27 16:09:33

[hasse69]

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 issue reported on code.google.com by hasse69 on 2013-07-28 08:21:01