Re: [MiNT] symlinks and hostfs

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

On Sun, 2009-08-30 at 00:01 +0200, Petr Stehlik wrote:
> Alan Hourihane píše v So 29. 08. 2009 v 22:07 +0100:
> > > 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 don't think anything. I just don't know, never used NFS, sorry.

You'd try to access the file and it'd say "File not found".

> In ARAnyM when we detect that the symlink goes beyond the mapped path I
> think we have about three choices:
> 
> A) remove (hide) the symlink from guest

Definate no.

> B) let it be broken

Yes, please. This is what happens on real filesystems with broken mount
points.

> C) Standa's real file simulator

Bad idea IMO. I've just tested this with a directory as a symlink. It
let's you actually change mount locations. But as Vincent, maybe as an
option it may be useful to some. But it sounds more of a security risk
to me.

> A has a problem - what if user tries to create a new file of the
> invisible symlink name
> 
> B has a problem - user might try to follow the symlink and start
> wondering why it's inaccessible when on the host the symlink works great

Not really, the user using ARAnyM should understand what they're trying
to do. This should be the default, again IMO.

> C - I don't see any downsides of this approach (but I haven't really
> thought about it). Do you?

Potentially offering access to files that wouldn't normally be allowed
given the symlink should be broken. It just doesn't match existing
filesystem semantics. Optional feature though seems fine.

> I am very sorry that Standa is not here to explain his thoughts and
> implementations on his own. While trying to do him an advocate I am just
> looking more and more like a moron.
> 
> > > 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.
> 
> Please just explain what would happen with NFS as I really don't know.
> 
> > But you said it was a "feature". That's why I didn't take this any
> > further. If you want to consider it as a bug
> 
> Well the implementation adds a special handling that doesn't have to be
> there - that's why I said that Standa implemented it as a intentional
> feature. It can be buggy by design or there can be a bug in the
> implementation but originally it was a feature, I believe.
> 
> > i.e. you can't access absolute links if they're in a different
> > location on the client.
> 
> Sorry, I don't understand. Please use simple and concrete examples so I
> can get it, thanks.
> 
> Currently from my limited testing in AFROS everything regarding symlinks
> seems to be working perfectly. I'd love to understand what you are
> seeing wrong. I can zip part of my file-tree or write a short yet clear
> examples how to create and check symlinks on host and guest using the
> AFROS.
> 
> One example of Standa's symlink converter in action ($ lines are entered
> in bash on the host):
> 
> 0) unpack afros812.zip in host /tmp
> 1) just for sure edit /tmp/afros/config and remove "D = /" line
> 2) $ cd /tmp/afros/drive_c && ln -s /etc ABC
> 3) $ aranym -c /tmp/afros/config -e
> 4) in Teradesk open C:, in the menu disable the "View -> Show As Icons",
> locate ABC folder (not a symlink but a "real" folder), open it and
> you're browsing in your host /etc - that's what Standa wanted to achieve
> and it's working OK. With a guest symlink this obviously wouldn't be
> possible.
> 
> Next example: normal symlink _stays_ symlink
> 
> 5) $ cd /tmp/afros/drive_c && ln -s olga.app samantha.prg
> 6) in Teradesk open C: and check the samantha.prg - it's a symlink
> (printed in italic)
> 
> What else... let's say creating a symlink in the guest
> 
> 7) in Teradesk select C:\acalc.acc and click File->New, a dialog for
> creating new symlink appears. Edit the symlink target and remove the
> absolute path "C:\" that is not necessary there, confirm OK
> 8) $ ls -l /tmp/afros/drive_c/ and you'll see the relative symlink. If
> you didn't remove the absolute path in Teradesk you'd get a symlink with
> target C:\acalc.acc - not useful on the host yet still fully working on
> the guest.
> 
> Now could you please show me what symlink problem are you having with a
> similar simple examples?

If you don't use NFS, there's no point in giving you an example as you
wouldn't be able to test it. But rest assured, the link would be
"broken" and in-accessible.

But I'm giving my opinion. All this stuff is open source and people are
free to do what they will, so I'm not advocating the change, just saying
that it doesn't match what I believe filesystems normally do.

Alan.