delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
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 | |
= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; 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; | |
s=default; bh=jJfWlXsYsPZEB63kEhTqhBPpO48=; b=RPtZn4MdNE61bGU3B | |
2J3/Kbdo/Z7I207c79WjLQoxtFaZixaC0H18yvZfAe0CHJoClJ8xoiDOme9LRqhq | |
3PvOe+FjZ/6IsdkSGvJ+4sDaA03rKijRkL4m+z/lIClw72R/KeXq4uLHvxzRnnfh | |
gCZlxciAUIkf4DHrJGJEzz/vQ4= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Virus-Found: | No |
X-Spam-SWARE-Status: | No, score=-1.5 required=5.0 tests=AWL,BAYES_20,RP_MATCHES_RCVD autolearn=ham version=3.3.2 |
X-HELO: | Ishtar.hs.tlinx.org |
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> |
X-IsSubscribed: | yes |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |