Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <17B78BDF120BD411B70100500422FC6309E216@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'Corinna Vinschen'" <cygwin AT cygwin DOT com>
Subject: RE: [ANNOUNCEMENT]: Important change to symbolic link functionali
	 ty
Date: Fri, 23 Feb 2001 12:14:27 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Corinna Vinschen [mailto:cygwin AT cygwin DOT com]
> Sent: Friday, February 23, 2001 9:34 AM
> To: cygwin
> Subject: Re: [ANNOUNCEMENT]: Important change to symbolic link
> functionali ty
> 
> 
> On Fri, Feb 23, 2001 at 10:52:31AM +0300, Andrej Borsenkow wrote:
> > 
> > >
> > > The shortcut contains a DOS path and a POSIX path. The 
> POSIX path is
> > > used by Cygwin or U/WIN. The DOS path is used by native 
> Windows tools,
> > > obviously.
> > >
> > 
> > That is, when I open shortcut properties in Explorer I see 
> DOS path? Then
> > there is a possibility that user changes shortcut there and 
> DOS/Cygwin paths
> > differ. One way to store paths checksums in .lnk; but it is 
> not clear what to
> > do in this case - you cannot recreate possibly relative 
> Unix path from changed
> > DOS one. Probably, in this case the right thing is to 
> invalidate Unix path in
> > shortcut alltogether.
> 
> It's exactly what is done by Cygwin. A shortcut created by Cygwin or
> U/WIN has a special header format which is sort of uncommon.
> Additionally, the R/O attribute is set and maintained by Cygwin and
> U/WIN. When a user changes a shortcut s/he has to remove the R/O
> attribute first. If that attribute isn't set the shortcut is 
> treated as
> a standard Explorer shortcut. If a user changes the content of the
> shortcut the header format changes since Explorer creates a completely
> different header. Even if the user sets back the R/O attribute the new
> header avoids that Cygwin uses the POSIX path in future and 
> the shortcut
> is treated as all other Explorer shortcuts. They are treated 
> as a symlink
> with only a DOS path pointing to the target.


FINE! :-))

You just have me raelize that your patch not only allows Explorer to follow
Cygwin symlinks, but also cygwin to follow Explorer shortcuts as if they
were Cygwin symlinks!

But what happens if i

	ln -s "C:/Somewhere/Something" something

Do I get a DOS shortcut or a mount-table dependant cygwin symlink with a dos
path set to "C:/Somewhere/Something"? Note that this is especially important
if, due to the mount table setup, C:/Somewhere/Something" is NOT accessible
using a cygwin path (because I've mounted something above "C:/Somewhere",
e.g:

	mount C:/ /
	mount C:/SomewhereElse	/Somewhere

Then "C:/Somewhere/Something" is no more accessible with a cygwin path (or
do it is by /cygdrive/c/Somewhere/Something ? I just wonder while typing...
Please excuse for the noise if it is).

Anyway don't take my word for a criticism: this is a REALLY good thing to
have some interoperability between cygwin symlinks and DOS shortcuts.

Thanks again,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple