Re: [MiNT] symlinks and hostfs

[Petr Stehlik <pstehlik@sophics.cz>]

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.

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
B) let it be broken
C) Standa's real file simulator

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

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

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?

Thanks,

Petr