Re: [Mingw-msys] NTFS directory symlinks
- Date: Thu, 13 Mar 2008 17:14:32 +0800
- From: "Xu Xiaogang-a19881" <nickxu@xxxxxxxxxxxx>
- Subject: Re: [Mingw-msys] One issue found in MSYS
Yes, I put a physical usr path at msys root directory. After moving the contents of it to msys root, the issue is gone.
Thanks for your help.
From: mingw-msys-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:mingw-msys-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Keith Marshall
Sent: 2008年3月13日 5:57
Subject: Re: [Mingw-msys] One issue found in MSYS
Please do not top post; I've rearranged this, to correct the flow.
On Wednesday 12 March 2008 15:53, Jamiil Abduqadir wrote:
> On Wed, Mar 12, 2008 at 10:49 AM, Brian Dessent <brian@xxxxxxxxxxx>
> > > Xu Xiaogang-a19881 wrote:
> > >
> > > When using MSYS1.0.11 version, I found a problem that MSYS
> > > recognized /usr as /, so the normal directory /usr/bin is
> > > recoginized as /usr/usr/bin. Everything in /usr/bin should be
> > > added a prefix "/usr" to be accessed.
> > > Does anyone meet the same problem as me? and how to fix this
> > > issue?
> > You haven't given much detail about your configuration. What is the
> > install root of MSYS, what is the install root of MinGW, what is the
> > contents of your /etc/fstab, and what is the output of running the
> > "mount" command?
> > The built-in loopback mounting of the MSYS install root to both "/"
> > and "/usr" is intentional. It ensures that commands can be referred
> > to as either /bin/sh or /usr/bin/sh for compatibility with *nix
> > while only having one actual underlying bin dir, and likewise for
> > /usr/lib and /lib. However this is done through the MSYS mount
> > table (i.e. path translation in the runtime) -- you should not
> > actually have a physical "usr" directory on disk anywhere. And
> > paths like /usr/usr/bin/sh should be inaccessible.
> Hey man, just try it!
> After all the installation or configurations are the standard 'windows
Huh? A *standard* MSYS install does *not* create, nor place anything into a *physical* %MSYS_ROOT%/usr directory; it has occasionally been suggested that creating one may be beneficial, but if you do this, it should remain empty.
> or are you using MSYS under Linux?
I'm sure Brian is *not* running MSYS under Linux; there would be no viable reason for doing this, unless you were developing components for MSYS itself, cross-compiling and testing under Wine, and I am not aware of any MSYS developer working this way.
Brian is completely correct in his description of the loopback mount arrangement for /usr on /; this *is* the way MSYS works, and yes, this
*is* on MS-Windows. So, since neither you nor the OP have given any details of your configuration, and in particular how you installed it to arrive at this broken setup, which you believe to be "standard", we can only guess at what you may have done. The most plausible scenario I can think of would be something like this:--
1) You've started out with a base system, and you've been adding the incremental update packages for MSYS-1.0.11.
2) Instead of using MSYS' own tar command to unpack the update tarballs, you've used WinZip, or some other *native* archive tool.
3) Some of the tarballs have been incorrectly packaged; when you unpack them with anything other than MSYS' own tar command, it incorrectly places components into a physical usr directory, where MSYS tar would resolve this via the loopback mount, and place those components directly into the MSYS root.
Would this be a reasonable guess, as to how you've done things? If so, then you should use the Windows Explorer -- the file system browser, not Internet Explorer -- to move everything out of the %MSYS_ROOT%/usr directory, into a similarly organised tree in %MSYS_ROOT% itself, and MSYS should then work correctly.
Obviously, this is a method to repair your broken installation; we need to repackage those improperly organised tarballs, so that others are not faced with the same problem in the future.
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
Mingw-msys mailing list
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Mingw-msys mailing list