From mint-bounce@lists.fishpool.fi Sat Aug 29 15:37:42 2009 Message-ID: In-Reply-To: <1251571200.23844.10.camel@jetpack.demon.co.uk> References: <4A97D65D.6090100@freesbee.fr> <1251471399.19057.103.camel@jetpack.demon.co.uk> <1251472068.19057.104.camel@jetpack.demon.co.uk> <4A97F60C.5040903@freesbee.fr> <1251473424.19057.108.camel@jetpack.demon.co.uk> <4A98472E.3010505@freesbee.fr <1251532244.3902.18.camel@joy> <1251550654.12642.71.camel@joy> <1251555169.21551.32.camel@joy> <1251561900.23844.7.camel@jetpack.demon.co.uk> <1251564592.4397.16.camel@joy> <1251571200.23844.10.camel@jetpack.demon.co.uk> Date: Sat, 29 Aug 2009 21:35:43 +0200 (CEST) Subject: Re: [MiNT] symlinks and hostfs From: "Petr Stehlik" To: "Alan Hourihane" Cc: mint@lists.fishpool.fi User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pstehlik@sophics.cz Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: > 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