Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-Id: <4.3.1.2.20010503104233.02700c48@pop.ma.ultranet.com> X-Sender: lhall AT pop DOT ma DOT ultranet DOT com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 May 2001 10:48:05 -0400 To: Martin Oberhuber , "'cygwin AT cygwin DOT com'" From: "Larry Hall (RFK Partners, Inc)" Subject: Re: Problem with Windows .lnk files treated as Symlinks In-Reply-To: <549191FE7B71D311BC5900104B292132010E4F8C@kirk.takefive.co. at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:27 AM 5/3/2001, Martin Oberhuber wrote: >Hello, > >since cygwin-1.3, Windows *.lnk files are treated as UNIX >symbolic links by default. > >We rean into a problem where we wanted to use the "cp" >command to copy a Windows *.lnk shortcut to a new place. >This worked alright with previous cygwin versions, but >with 1.3, the file referenced was copied instead of the >*.lnk file. > >One problem with this behavour is that additional attributes >of the *.lnk file (like parameters passed to the program >referenced, or an icon associated) are not copied in that >case. > >Looking at options of the CYGWIN environment variable as >well as options of the "cp" command, I found NO WAY of >copying the *.lnk file instead of the file referenced! >Even "cp -d", which is documented to preserve symbolic >links (and works like that on Linux) did not work. >Setting CYGWIN=nowinsymlinks only affects link creation, >but not link interpretation by "cp". > >Taking into account that Windows Shortcuts are more than >UNIX symbolic links, and that thus a one-to-one mapping >is always problematic, I would suggest the following to >preserve a clean environment as well as backward >compatibility: > >1.) Only *.lnk files created by Cygwin (with the special > cygwin header), should be treated as symbolic links when > they are read. If the *.lnk file is not a "cygwin *.lnk" > with its special header, it should be treated as a plain > file. > If this is not observed, important information may be lost > (also think about programs like tar that cannot reproduce > an exact image of the original file system if *.lnk files > are not completely copied). Since the goal of making Cygwin symbolic links use the Windows short-cut mechanism was to allow Windows and Cygwin to interoperate in this area, I don't see any benefit to trying to break this with your suggestion. Certainly, this is the way things worked prior to this change since short-cuts were not understood by Cygwin and Cygwin symbolic links were not understood by Windows. If you need this division, you want to use the old mechanism. >2.) If CYGWIN=nowinsymlinks is set, not only symbolic link > creation but also symbolic link interpretation should > be "classical", i.e. *.lnk files are treated as files. This may be indicative of a bug. >Please keep me informed on your plans regarding this issue. Watch the list and you'll see any discussion of this. Or send in a patch for (2) for consideration. Larry Hall lhall AT rfk DOT com RFK Partners, Inc. http://www.rfk.com 118 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple