This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: usefulness of symlinks (was: cygserver-config script installed inconsistent path in registry)


Corinna Vinschen wrote:
On Mar 21 16:03, Linda Walsh wrote:
 both think
they are running under C:/bin (which is a symlink ->
cygwin64/bin, through C:\windows\system32\cygwin)

Why did you mess around with the install paths that badly?  Don't
install anything Cygwin into C:\windows.
----
   Strictly speaking, nothing "cygwin" is in C:\windows --
there are only "pointers" ;-)

More specifically: There are two symlinks.

   1) under C:\Windows\System32 (cygwin->C:\cygwin64)
   2) under C:\Windows\SysWOW64 (cygwin->C:\cygwin).

Why?

  Because it is the only place you can get automatic redirectly
based on what bit-size (64 v. 32) you are running at.


The script just calls cygrunsrv.  cygrunsrv fetches it's own path via
the Win32 API GetModuleFileName and that API returns the path apparently
cleaned from symlinks.
---
   Is there a reason why it needs or why it should do that?

   It would be nice if there was a way to provide path transparency
to cygwin apps -- i.e. you guys do a good job of calling all the types
of redirection "symlinks", but windows doesn't really have any easy
way to remount a subpath -- might be nice to have an  option to treat
say, 'linkd' links as 'mounts' rather than symlinks, since
'mountvol' only works for complete volumes...

   I.e. linkd could be a limited substitute for mount --bind

   (reason I mention that is that I have to manually move files
after running setup)...

   Theoretically, /usr/share, should be "shareable" and contains
the most amount of data by itself.

   There might be others, but /usr/share was created to have
arch-independent data on it.

   I wouldn't call any of it a high priority item, as I doubt I'll
use 32-bit as much... but I probably will try the GLgears on 32-bit
to see if that still works there (as it doesn't on 64-bit -- gears
display but don't move, but window the gears are in is a directX
window -- 'FRAP' (Frame Rate util) displays a counter  in the window
which it only does in directX mapped windows (showing 30FPS -- it's
an LCD so doesn't need or benefit from 60).

   If it does work, I might want to continue 32 bit just for
the X-stuff until the 64bit gets sorted out... I know everyone is
doing whatever they can to make things work and all things can't
be done at the same time....  It's just that my linux distro's (opensuse)
desktops are all opening up GLX enabled windows -- so w/o that
working no remote desktop usage.  ;-(

   I was just pluggin cygwin, today over it's X-server for people
wanting a remote access to their opensuse desktops, and were talking
Xming... I know cygwin's GLX used to work... oh well.  Maybe just
a 64-bit thing.


	

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]