Re: [MiNT] symlinks and hostfs

[Alan Hourihane <alanh@fairlite.co.uk>]

On Sat, 2009-08-29 at 21:35 +0200, Petr Stehlik wrote:
> > On Sat, 2009-08-29 at 18:49 +0200, Petr Stehlik wrote:
> >> > Getting back to my patch, it uses lstat() exclusively in all cases.
> >> > Using stat() will end up stat'ing the wrong file when symlinks are
> >> > being checked. This looks like a bug in ARAnyM to me
> >>
> >> I have tried to explain that it supposed to be a feature, not a bug. Did
> >> you read my explanation? Did it make sense?
> >
> > I did read your explanation and it didn't make sense
> 
> Let me show you an example. On the linux host you have a directory
> /home/aranym and it's mapped as GEMDOS drive E: in HostFS.
> 
> So whenever you invoke "ls -l /e/" in FreeMiNT you see the files that are
> in /home/aranym path on the host.
> 
> Now you create a symlink _on the host_:
> 
> $ cd /home/aranym && ln -s /etc/hosts && ls -l hosts
> lrwxrwxrwx 1 joy joy 10 2009-08-29 21:22 hosts -> /etc/hosts
> 
> Back to FreeMiNT, again "ls -l /e/". There is a new symlink named "hosts"
> that points to nowhere - (outside of E:). With your proposed hostfs.cpp
> patch this "hosts" is shown as a symlink - so far so good. Though if you
> try to open the symlinked file it fails because FreeMiNT cannot get the
> target filename as it's not in the directory tree mapped as E: - there is
> simply no representation of the filename on the guest side. So the symlink
> is broken.
> 
> I don't know the reason behind this but Standa invented the special
> feature (that your proposed patch removes) that in order to make this (and
> only this) file accessible it "converts" the symlink on the host and
> represents it as a real file for the guest so the guest can read/write
> that file.

In your example, consider this. If you think of the host as an NFS
server, and ARAnyM as an NFS client. If you export /home/aranym and
mount it on the client under /mnt/disk what do you think would happen
with the symlink ?

> >> > I've posted a patch to help demonstrate the problem with ARAnyM,
> >> > which cures the problem for me
> >>
> >> I didn't know you had a symlink problem as well. Can you please show me
> >> where the symlink pointed to? Was it outside of the mapped paths? And
> >> could you read the contents of the symlinked file before and after the
> >> hostfs.cpp patch? And last thing: could you please re-try that without
> >> ARAnyM patch with stock AFROS 8.12? It helped Vincent so I am wondering
> >> if it helped you, too.
> >
> > Then, this problem isn't an issue if symlinks are never treated as
> > symlinks as it's a feature of aranym.
> 
> "symlinks are never treated as symlinks" is not the case. Just those rare
> symlinks that point outside of mapped paths are being represented as real
> files.

Consider my NFS example above.

> Note also that I don't say that this is necessarily a great thing. If it
> looked like this broken symlink conversion has more cons than pros I could
> simply disable it. Let me know your opinion...

Again, look at the NFS example.

> > Move along, nothing to be seen here.
> 
> I am just trying to fix bugs and solve known problems before releasing a
> new version. If there is a problem with symlinks I'd like to understand it
> and fix it. Your proposed hostfs.cpp patch disables functionality that is
> normally (=for symlinks created from the guest) not affecting anything so
> I am wondering how it could help you.

But you said it was a "feature". That's why I didn't take this any
furthur. If you want to consider it as a bug, then the NFS example
demonstrates the same problem. i.e. you can't access absolute links if
they're in a different location on the client. A relative link should be
accessible, as long as it's in the mount point, i.e. don't go too far
back using ../../../.. that you end up back in the local filesystem and
then can't reference the link anyway.

Alan.