DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=VWoKF2Cqp0xKNf0PTeCwEvy8oJJcf2Nt6mrWkjOA8Z7
	y7zu9MJpDPwyP5J5fi9MDvqlOK/YqTevQIe51U0x3aDrVNN1gg2ndYKF7NgXiY32
	M24nnyeF/YF3aITo5gmCeoAmP/vFQU0YXsdneRhlabYA3iz+m+2jXO0b0ciRsnjA
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <54138198.9060400@tlinx.org>
Date: Fri, 12 Sep 2014 16:28:24 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: bi-arch cygwin (was Re: /usr/local/bin symbolic link disappears every time cyg setup is run)
References: <CAMQzRBp_wiGu76q8_e42+vE=uo_fHzQU6j6wh-0DDjtP2AVkHw AT mail DOT gmail DOT com>
In-Reply-To: <CAMQzRBp_wiGu76q8_e42+vE=uo_fHzQU6j6wh-0DDjtP2AVkHw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dat Head wrote:
> I have a symlink from /usr/local/bin to /3TB-external/bin/CYGWIN to keep
> architecture independent bin files on an external drive for portability.
----
    I've tried similar and wasn't able to convince anyone (my track
record on being convincing is significantly lamer than mosts').

    I thought this (https://cygwin.com/ml/cygwin/2014-03/msg00494.html)
was the best solution to fix this problem.

    I first mentioned it in
this: (https://cygwin.com/ml/cygwin/2014-01/msg00089.html)
post and would love to see it work.

As it is, I have to manually recreate the links and manually copy
programs installed at the wrong location after each install.

Re: solutions to use a cygwin mount point:

Kurt Franke wrote:
> I just use /usr/local as a mount point:
> $> df /usr/local/
> D:/cygwin-local/usr/local 766838780 405249584 361589196  53% /usr/local
> setup may create any structure under this mount point,
> but this has no effect in cygwin...
and

Achim Gratz wrote:
> Just create a mount in /etc/fstab and keep the tree under the mount
> point empty.

----
Miss the point -- I want setup to write into the shared location
for /usr/share or any specific mount point.

Both "mountvol" and "linkd" create "junctions" which are called
soft mount points by microsoft vs. "mklink", which actually
creates something called a "symbolic link".

Under cygwin, linkd-created junctions are treated like symlinks.
I lobbied (unsuccessfully) to get this changed.  The stumbling
block was a fear of this creating directory loops -- which cygwin
already creates via it's own soft mounts (or so "find" tells me
when doing a rebuild of the "locate" db.

The same behaviors happen on linux with it's mount program
redirecting files and directories... the device num doesn't
change -- and loops can result.  But linux took the path of
providing the feature and not second-guessing how users
and admins should configure their computer.  When MS
implemented junctions in Win2k, they said that uncareful
use could result in directory loops. 

It is unfortunate that cygwin should have eliminated
the usefulness of MS's directory remounting (as this
would have kept this feature in parity with linux).


>
> every time I run cyg setup.exe it removes the symlink and creates an
> empty /usr/local/bin directory - is it really supposed to do that?
> are there some cygwin pkgs (none that I have installed because it has
> never put anything there) that put files there? (even if there are,
> it shouldn't zap the symlink)
----
If it doesn't put files in there, then why would it delete the symlink?

That seems like a malicious enforcement of a broken paradigm.


Note, this allows this type of structure:

>  ll / |grep cyg|cut -c42-999
bin -> /windows/system32/cygwin/bin/
bin1 -> /windows/system32/cygwin/bin/
cygcommon/
cygwin/
cygwin64/
etc -> /Windows/system32/cygwin/etc/
lib -> /Windows/System32/cygwin/lib/
sbin -> /Windows/System32/cygwin/sbin/
usr -> /Windows/System32/cygwin/usr/
var -> /Windows/System32/cygwin/var/


Then the link in /windows/system32 is handled by windows:

(under 32 bit windows:)
C:\cygwin\bin>uname -a
CYGWIN_NT-6.1-WOW64 Athenae 1.7.28(0.271/5/3) 2014-02-09 21:06 i686 Cygwin
C:\cygwin\bin>dir \windows\system32|grep cyg
01/10/2014  01:09 PM    <SYMLINKD>     cygwin [C:\cygwin]

(64-bit windows:)
C:\bin>uname -a
CYGWIN_NT-6.1 Athenae 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin
C:\bin>dir C:\windows\system32|grep cygwin
01/11/2014  09:21 PM    <SYMLINKD>     cygwin [C:\cygwin64]

So depending on whether you are running 32-bit or 64-bit, the *redirector*
link in /windows/<syswow64|system32>/  redirects you to the compatible
architecture (or should if everything was put together correctly.

Unfortunately, w/o any "soft-mount" support by honoring window's linkd
entries, it's not easy to maintain this type of setup (as you can tell
from the "uname" output -- my 32-bit cygwin doesn't get updated
as often... ;-(

Anyway, just a rehash of what a bi-arch cygwin might look like
and how it could be implemented.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple