Re: [fuse-devel] Symbolic links across file system boundaries

[Hans B. <han...@gm...>]

On Saturday, July 27, 2013, Nikolaus Rath wrote:

> Hans Beckerus <han...@pu...>
> writes:
> > On 2013-07-27 5:21, Nikolaus Rath wrote:
> >> Hans Beckerus <
> han...@pu...>
> writes:
> >>> I recently received an issue report regarding my filesystem not
> properly
> >>> following symbolic links.
> >> A fuse file system is not responsible for following symlinks. That's
> >> handled in the kernel.
> >>
> >>> The problem as reported was that files/folders were linked to but
> >>> located outside the FUSE mount point (!?) and thus not handled
> >>> properly.  I closed that case with reference to the limitation that
> >>> symbolic links across file system boundaries are not supported by fuse
> >>> (nor any other files system IIRC).
> >> What you're saying here doesn't make any sense to me. There are no
> >> restrictions on where symbolic links can point in any file system.
> >
> > Correct. My bad. We are talking soft links here.
>
> In my terminology, a soft link and a symbolic link are the same
> thing. There are two kinds of links: (1) soft/symbolic links that have
> their own inode, and the inode stores the path of the link target and
> (2) hard links, which are multiple directory entries pointing at the
> same inode. The former can point at anything, the link target is just a
> string. The later can only work within the same file system.
>
> Which of those are you talking about?
>
> Symbolic links then ;)


> >> What exactly happens if you try to access the symbolic link, and what
> >> makes you think that fuse is responsible for whatever the problem is?
> >
> > The link is followed properly at eg. 'ls' like operations. But, since it
> > points to a place which is not covered by my fs mount point, the proper
> > actions/filters are not triggered (!?).
>
> What proper actions do you mean?

Proper in the sense that the semantics of my file system is not triggered.
The link (which is inside my file system) is followed just fine but it does
only list the files at eg. ls operations. Nothing of the specifics
implemented by my file system is executed on the link target. Which I think
is normal since the link target is "outside" my file system mount point.

>
> > I also tried to create two mount
> > points and link (ln -s) between the two but that caused fuse library to
> > throw an error.
>
> What error? At what point?
>
> The error is because I do not implement the symlink() call-back which
means I can not create symbolic links on a live mounted file system.
Nothing to worry about really. I can implement it but that is not really
the issue that I am trying to resolve.


> > I am only guessing here, but since the link target is in
> > a path not covered by my file system, is this type of links not expected
> > to fail?
>
> When you are talking about symlinks/softlinks: no.
>
> > Replacing the soft link with a bind mount works much better in this
> > case. What I am trying to pin down here is if I have missed something in
> > my filesystem implementation or not.
>
> For symlinks, all your file system has to do is provide a correct
> readlink()
> implementation. Everything else is handled in the kernel.
>
> And that I do. As I said, symlinks are followed just fine. Let me
elaborate a bit. My question is rather this (long version):
Is it expected that my file system specifics are supposed to be triggered
on a symbolic link if the link target is "outside" my file system mount
point? I would say no, but I just need some feedback on that assumption.
Lets say we have two folders, a1 and b1 were a1 has symbolic links to
files/folders inside b1. I mount a1 on eg. a2 using my file system. Now the
symbolic links are displayed/followed properly in a2 but when actions are
performed on those links my file system call-backs, such as readdir(), are
never called. This is the "issue report" I received which I also closed by
stating it is not supported and expected behaviour;) Additionally, to
support this theory I also mounted b1 on b2 using my file system (a second
instance of it) and changed the links in a1 to instead point to files
inside b2. Viola! Now it works. So, was my response to this issue correct
or is there some mechanism that I could have implemented to work around
this?
In my response I suggested that both the symbolic link and the actual link
target should be covered within the same mount point (fs instance) or
otherwise use bind mounts instead of symbolic links.


>
> Best,
>
>    -Nikolaus
>
> --
>  »Time flies like an arrow, fruit flies like a Banana.«
>
>   PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> fuse-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>