Re: [MiNT] symlinks and hostfs

["Petr Stehlik" <pstehlik@sophics.cz>]

> 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.

>> > 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.

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...

> 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.

Thanks

Petr