MSYS using Junctions quirk

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

MSYS using Junctions quirk

dmccunney
I'm not sure whether I'm encountering a bug or just getting bitten by
lack of knowledge.

I have an ancient Fujitsu p2110 notebook, given to me by a friend when
she upgraded to a faster box.  It's decidedly low end, with a
Transmeta 867mhz CPU, an IDE 4 HD, and a whopping 256MB of RAM, of
which 16MB are taken off the top by the CPU for "code morphing".  It
came to me with WinXP SP2 installed, and was frozen snail slow.  I
swapped the original 30GB HD for a 40GB from my SO's dead laptop,
reformatted, partitioned, and installed Win2K Pro SP4, two flavors of
Linux, and FreeDOS.  Properly tuned and configured, Win2K takes about
80MB of RAM when loaded, and is actually usable.  (Most of what I
might need to run under Windows works in 2K.  The stuff that doesn't I
can live without.)

I installed the MYS tools because I wanted a set of Win32 ports of the
common *nix utilities, and a working Win32 version of bash.  I did not
install the MinGW compiler and associated tools - the machine is way
too underpowered to do development on it.

NTFS5 supports hard links for files and junctions for directories.  I
use Hermann Schinagl's Link Shell Extension
(http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html)
which provides context menu entries to create and manipulate such
things.  Under Win2K/WinXP it does hard links out of the box.  Under
Vista/Win7 it supports proper symbolic links, too.*

I wanted a *nix like file system, so I used LSE to create a junction,
and have Msys/1.0/bin appear as /bin.  That works fine.  I
subsequently decided I'd prefer it to appear as /usr/bin, deleted the
old junction, and created a new one.  That did *not* work fine.  The
junction was created, /usr/bin shows in the file system and I can list
the files in it, but attempting to actually execute any of them fails.
 I can type the command at the prompt and I simply return to the
prompt with the command not actually running.  If I create the
junction as /bin, things work.  It appears Msys tools only work
correctly through junctions created off of root, and fail if the
junction is created off a sub-directory.  This seems to be Msys
specific, as I have other sets on Win32 ports of *nix utilities, like
the Gnuwin32 collection, that do work as expected.

Right now, I have Msys mapped via a junction as /bin, and can live
with it.  But I'm curious: *should* creating the junction as /usr/bin
have worked, or am I running into an inherent limit in how Msys works,
or have I found a bug?

* And too my surprise, a recent update to LSE pointed to an open
source driver written by a Japanese developer that enables true
symlinks in 2K and XP.  NTFS5 has the underlying infrastructure to
support symlinks, but it's not exposed by the 2k/XP kernel.  The
driver amends that oversite.

______
Dennis
https://plus.google.com/u/0/105128793974319004519

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

Earnie Boyd
On Mon, Aug 27, 2012 at 6:12 PM, dmccunney wrote:
> I'm not sure whether I'm encountering a bug or just getting bitten by
> lack of knowledge.
>

The latter is what I'm thinking.  BTW, support for MSYS happens on
mingw-user, the documentation needs changed.

>
> NTFS5 supports hard links for files and junctions for directories.  I
> use Hermann Schinagl's Link Shell Extension
> (http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html)
> which provides context menu entries to create and manipulate such
> things.  Under Win2K/WinXP it does hard links out of the box.  Under
> Vista/Win7 it supports proper symbolic links, too.*
>
> I wanted a *nix like file system, so I used LSE to create a junction,
> and have Msys/1.0/bin appear as /bin.  That works fine.  I
> subsequently decided I'd prefer it to appear as /usr/bin, deleted the
> old junction, and created a new one.  That did *not* work fine.  The
> junction was created, /usr/bin shows in the file system and I can list
> the files in it, but attempting to actually execute any of them fails.
>  I can type the command at the prompt and I simply return to the
> prompt with the command not actually running.  If I create the
> junction as /bin, things work.  It appears Msys tools only work
> correctly through junctions created off of root, and fail if the
> junction is created off a sub-directory.  This seems to be Msys
> specific, as I have other sets on Win32 ports of *nix utilities, like
> the Gnuwin32 collection, that do work as expected.
>
> Right now, I have Msys mapped via a junction as /bin, and can live
> with it.  But I'm curious: *should* creating the junction as /usr/bin
> have worked, or am I running into an inherent limit in how Msys works,
> or have I found a bug?
>

Why?  When you start the MSYS shell it maps itself already to / and
/usr.  What are you trying to accomplish?

> * And too my surprise, a recent update to LSE pointed to an open
> source driver written by a Japanese developer that enables true
> symlinks in 2K and XP.  NTFS5 has the underlying infrastructure to
> support symlinks, but it's not exposed by the 2k/XP kernel.  The
> driver amends that oversite.

MSYS when I forked Cygwin to develop it did not have a Windows
junction or a Windows symlink to rely on and the way Cygwin had
emulated it did not work for a native application.  Therefore it was
removed and the functions return ENOSYS error.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

dmccunney
On Tue, Aug 28, 2012 at 8:12 AM, Earnie Boyd
<[hidden email]> wrote:
> On Mon, Aug 27, 2012 at 6:12 PM, dmccunney wrote:
>> I'm not sure whether I'm encountering a bug or just getting bitten by
>> lack of knowledge.
>
> The latter is what I'm thinking.  BTW, support for MSYS happens on
> mingw-user, the documentation needs changed.

So noted. Thanks.

>> Right now, I have Msys mapped via a junction as /bin, and can live
>> with it.  But I'm curious: *should* creating the junction as /usr/bin
>> have worked, or am I running into an inherent limit in how Msys works,
>> or have I found a bug?
>
> Why?  When you start the MSYS shell it maps itself already to / and
> /usr.  What are you trying to accomplish?

Like I said, a Unix style file system arrangement.  *Msys* may map
itself to / and /usr, but I'm not always *in* the Msys shell when I''m
in a console.  Aside from Msys bash, I have versions of tcsh, zsh, and
ksh, as well as Windows cmd.exe.  They don't see the Msys mapping.  (I
use Console2 to get a tabbed console window, and may have more than
one shell active at a time.)

>> * And too my surprise, a recent update to LSE pointed to an open
>> source driver written by a Japanese developer that enables true
>> symlinks in 2K and XP.  NTFS5 has the underlying infrastructure to
>> support symlinks, but it's not exposed by the 2k/XP kernel.  The
>> driver amends that oversite.
>
> MSYS when I forked Cygwin to develop it did not have a Windows
> junction or a Windows symlink to rely on and the way Cygwin had
> emulated it did not work for a native application.  Therefore it was
> removed and the functions return ENOSYS error.

I assumed something like that.  Native support now exists (for
Vista/Win7, at least.)  Any plans to add it to Msys?

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

Earnie Boyd
On Tue, Aug 28, 2012 at 11:49 AM, dmccunney wrote:

>>> Right now, I have Msys mapped via a junction as /bin, and can live
>>> with it.  But I'm curious: *should* creating the junction as /usr/bin
>>> have worked, or am I running into an inherent limit in how Msys works,
>>> or have I found a bug?
>>
>> Why?  When you start the MSYS shell it maps itself already to / and
>> /usr.  What are you trying to accomplish?
>
> Like I said, a Unix style file system arrangement.  *Msys* may map
> itself to / and /usr, but I'm not always *in* the Msys shell when I''m
> in a console.  Aside from Msys bash, I have versions of tcsh, zsh, and
> ksh, as well as Windows cmd.exe.  They don't see the Msys mapping.  (I
> use Console2 to get a tabbed console window, and may have more than
> one shell active at a time.)

So the issue becomes this, for MSYS it maps / and /usr to the parent
of the directory containing the msys-1.0.dll and the directory
containing msys-1.0.dll becomes /bin and /usr/bin.  When you create
the junction c:/usr/bin to the msys/1.0/bin and execute from
c:/usr/bin then root / is then mapped to c:/usr and MSYS is all
confused.

The tcsh, etc shells, are the Cygwin related or something else?

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

dmccunney
On Tue, Aug 28, 2012 at 1:09 PM, Earnie Boyd
<[hidden email]> wrote:

> On Tue, Aug 28, 2012 at 11:49 AM, dmccunney wrote:
>>>> Right now, I have Msys mapped via a junction as /bin, and can live
>>>> with it.  But I'm curious: *should* creating the junction as /usr/bin
>>>> have worked, or am I running into an inherent limit in how Msys works,
>>>> or have I found a bug?
>>>
>>> Why?  When you start the MSYS shell it maps itself already to / and
>>> /usr.  What are you trying to accomplish?
>>
>> Like I said, a Unix style file system arrangement.  *Msys* may map
>> itself to / and /usr, but I'm not always *in* the Msys shell when I''m
>> in a console.  Aside from Msys bash, I have versions of tcsh, zsh, and
>> ksh, as well as Windows cmd.exe.  They don't see the Msys mapping.  (I
>> use Console2  to get a tabbed console window, and may have more than
>> one shell active at a time.)
>
> So the issue becomes this, for MSYS it maps / and /usr to the parent
> of the directory containing the msys-1.0.dll and the directory
> containing msys-1.0.dll becomes /bin and /usr/bin.  When you create
> the junction c:/usr/bin to the msys/1.0/bin and execute from
> c:/usr/bin then root / is then mapped to c:/usr and MSYS is all
> confused.

And that confusion accounts for the fact that the various mys tools
simply silently fail when executed from /usr/bin.  (I assume they set
a non-zero exit status of some kind.)  Okay.  That explains what's
going on.

I have Cygwin as well (though not currently used on the notebook,) but
I'd prefer to avoid the quirks involved in trying to use such tools
from outside their native environment.  I want to have such tools in
my Windows PATH, execute them from CMD.EXE as well as whatever their
native shell might be, and expect reasonable results.  Like I said,
I'm not trying to do development on the box, so GCC and the like are
irrelevant.  I just want to do things like type ls -l at a prompt, get
a long form ls listing, and not care about just which prompt I'm doing
it from.

> The tcsh, etc shells, are they Cygwin related or something else?

Something else.  There are lots of third-party ports of Unix tools to
Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils
(http://unxutils.sourceforge.net/UnxUtils.html)  Zsh is Syring's port,
though there are a couple of others,  Just poking around on
Sourceforge, I've seen a POSIX compatibility layer implemented as a
device by a Russian developer, and installed by Add/Remove Hardware,
and an offering called PW32 that looks like it's trying to do
something similar to Msys. (That one hasn't been updated in a while,
and appears moribund.)

Everyone seems to implement a different set of the tools, and a
background effort here is to get the fullest possible set, which means
mix and match, with preference given to the most recent version
ported,

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

Earnie Boyd
On Tue, Aug 28, 2012 at 1:38 PM, dmccunney wrote:
>
>> The tcsh, etc shells, are they Cygwin related or something else?
>
> Something else.

Ok, good.  There could be issue with mixing these environments.

> There are lots of third-party ports of Unix tools to
> Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils
> (http://unxutils.sourceforge.net/UnxUtils.html)  Zsh is Syring's port,
> though there are a couple of others,  Just poking around on
> Sourceforge, I've seen a POSIX compatibility layer implemented as a
> device by a Russian developer, and installed by Add/Remove Hardware,
> and an offering called PW32 that looks like it's trying to do
> something similar to Msys. (That one hasn't been updated in a while,
> and appears moribund.)
>

I'll caution you with some of these.  IIRC, Zsh contains a fork
implementation based on Cygwin's fork and from what I remember isn't
being updated recently.  The last update of unxutils was in 2007;
pretty old but if it works, so be it.

PW32 is pretty much dead.  The developer used to communicate with the
MinGW team.

> Everyone seems to implement a different set of the tools, and a
> background effort here is to get the fullest possible set, which means
> mix and match, with preference given to the most recent version
> ported,

And everyone tends to have varying goals.  MSYS was started to provide
a means for MinGW to execute a typical configure and make process for
building native tools.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

dmccunney
On Tue, Aug 28, 2012 at 2:53 PM, Earnie Boyd
<[hidden email]> wrote:
> On Tue, Aug 28, 2012 at 1:38 PM, dmccunney wrote:
>>
>>> The tcsh, etc shells, are they Cygwin related or something else?
>>
>> Something else.
>
> Ok, good.  There could be issue with mixing these environments.

Which is why I want to be aware of issues.  Mysy mounts are one such:
it looks like I ought not to mix Msys tools with others.  The Gnuwin32
toolset looks like a reasonably good set of the standard command line
tools.  The fun part is a *nix like shell.  I started using Unix with
SysVR2 and am an old Korn shell guy, but if it uses the Bourne script
language and has decent interactive features like command line
editing, aliases, and functions, I can deal. This means bash, mksh,
and zsh are usable, but lets out tcsh for anything save occasional
use.  Back in the MS-DOS days, I used the MKS Toolkit, largely because
they *had* a good Korn shell port.

>> There are lots of third-party ports of Unix tools to
>> Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils
>> (http://unxutils.sourceforge.net/UnxUtils.html)  Zsh is Syring's port,
>> though there are a couple of others,  Just poking around on
>> Sourceforge, I've seen a POSIX compatibility layer implemented as a
>> device by a Russian developer, and installed by Add/Remove Hardware,
>> and an offering called PW32 that looks like it's trying to do
>> something similar to Msys. (That one hasn't been updated in a while,
>> and appears moribund.)
>
> I'll caution you with some of these.  IIRC, Zsh contains a fork
> implementation based on Cygwin's fork and from what I remember isn't
> being updated recently.  The last update of unxutils was in 2007;
> pretty old but if it works, so be it.

The UnxUtils tools seem to work well enough.  I have a couple of
different versions of zsh, of which one is Syring's.  But they are
based on older versions of zsh, that don't support things like
--version, so it isn't terribly clear what zsh code they were based
on.  (I know,  Look at the source...)

> PW32 is pretty much dead.  The developer used to communicate with the
> MinGW team.

Since it hasn't been updated in some time, that was my assumption.  I
was fascinated it existed, but unsurprised it was moribund.  I've lost
count of the number of promising open source offerings I've seen that
withered because the devs lost interest/didn't have time/whatever, and
they never achieved enough traction to induce someone else to pick
them up.

>> Everyone seems to implement a different set of the tools, and a
>> background effort here is to get the fullest possible set, which means
>> mix and match, with preference given to the most recent version
>> ported,
>
> And everyone tends to have varying goals.  MSYS was started to provide
> a means for MinGW to execute a typical configure and make process for
> building native tools.

Yep, and it apparently does it well .  I just don't happen to be doing
that.  All I need is a decent set of the standard command line tools
used outside of the development process, and access to a *nix like
shell on occasion.

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

Earnie Boyd
On Tue, Aug 28, 2012 at 3:30 PM, dmccunney wrote:

>
> Which is why I want to be aware of issues.  Mysy mounts are one such:
> it looks like I ought not to mix Msys tools with others.  The Gnuwin32
> toolset looks like a reasonably good set of the standard command line
> tools.  The fun part is a *nix like shell.  I started using Unix with
> SysVR2 and am an old Korn shell guy, but if it uses the Bourne script
> language and has decent interactive features like command line
> editing, aliases, and functions, I can deal. This means bash, mksh,
> and zsh are usable, but lets out tcsh for anything save occasional
> use.  Back in the MS-DOS days, I used the MKS Toolkit, largely because
> they *had* a good Korn shell port.
>

Bash has decent emulation for standard Bourne shell syntax when named
sh and has some ksh features.
http://web.mit.edu/gnu/doc/html/features_3.html

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: MSYS using Junctions quirk

dmccunney
On Tue, Aug 28, 2012 at 4:07 PM, Earnie Boyd
<[hidden email]> wrote:

> On Tue, Aug 28, 2012 at 3:30 PM, dmccunney wrote:
>>
>> Which is why I want to be aware of issues.  Mysy mounts are one such:
>> it looks like I ought not to mix Msys tools with others.  The Gnuwin32
>> toolset looks like a reasonably good set of the standard command line
>> tools.  The fun part is a *nix like shell.  I started using Unix with
>> SysVR2 and am an old Korn shell guy, but if it uses the Bourne script
>> language and has decent interactive features like command line
>> editing, aliases, and functions, I can deal. This means bash, mksh,
>> and zsh are usable, but lets out tcsh for anything save occasional
>> use.  Back in the MS-DOS days, I used the MKS Toolkit, largely because
>> they *had* a good Korn shell port.
>
> Bash has decent emulation for standard Bourne shell syntax when named
> sh and has some ksh features.
> http://web.mit.edu/gnu/doc/html/features_3.html

Yep.  I use bash under Linux (and I'm up under Ubuntu 12.04 LTS at the
moment.)  The bash developers appeared to be trying to include
everything *including* the kitchen sink, and produced what you might
get if you merged sh, ksh, and csh in one shell.  In the process, it
got big and resource intensive enough that we got ash, with the shell
language but without the interactive stuff, specifically to run things
like install scripts with less overhead.  (I found one ancient
win-bash port based on bash 1.x, and the FAQ answer to "Why not a more
recent version" is "It runs the scripts we wanted to be able to run.")

AT&T made the real ksh open source, but their license isn't compatible
with things like the GPL, so Cygwin can't include it, and I haven't
seen a Windows version other than AT&T's UWin environment.

(Incompatible licenses are probably the biggest open source stumbling
block I can think of.)

> Earnie
> -- https://sites.google.com/site/earnieboyd
______
Dennis
https://plus.google.com/u/0/105128793974319004519

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys