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
	:content-type:content-transfer-encoding; q=dns; s=default; b=wL+
	860Te+tUk5ZSVwIm1KG+53xzuvDJiUx6h1jrkSNkOuEha9V22rE/d4IGjyPILddV
	JJcqIeqvHFWKm1fm15mmG/ue051FyZyCcBLuhnlDdlsKB8AjxoIEGjaR7ngH0uRn
	L77N0CQrghz1lwjALvdCI40i4b2tgh1faZY3J1U0=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <542A219C.6070402@ptc.com>
Date: Mon, 29 Sep 2014 22:21:00 -0500
From: Brian Ericson <bericson@ptc.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: <cygwin@cygwin.com>
Subject: Native symbolic links to non-existent targets (possible bug?)
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Note-from-DJ: This may be spam

Cygwin appears to ignore "winsymlinks:native" when asked to create a 
symbolic link to a non-existent target, reverting to its "magic header" 
approach.

This can be demonstrated via the following examples (using a Cygwin shell):
   echo hello > aaa
   ln -s aaa bbb
   notepad bbb

   ln -s xxx yyy
   notepad yyy

"notepad bbb" will show "hello", but "notepad yyy" produces "㰡祳汭湩 
㹫﻿xxx ".  "bbb" is a native symbolic link, "yyy" is not.  (This can 
also be confirmed using "dir" (cmd.exe /c dir from within Cygwin) or 
looking for the curved arrow glyph in the folder explorer.)

Note that this is in contrast to mklink (using a command prompt):
   echo hello > aaaa
   mklink bbbb aaaa
   notepad bbbb

   mklink yyyy xxxx
   notepad yyyy

In this case, both mklink commands succeed; "notepad bbbb" works as 
expected, and "notepad yyyy" pops up an alert with "Cannot find the yyyy 
file. Do you want to create a new file?", which makes sense (it even 
writes to xxxx if you say "yes").

Also, mklink-created symbolic links to non-existent targets appear to 
work (just as they do on *nix) when the non-existent target is created:
   echo hello again > xxxx
   notepad yyyy

The result is now "hello again".

I initially stumbled upon this discrepancy in the following real-world 
example:
   git init foo
   cd foo
   touch .gitignore
   git add .gitignore
   git commit -m 'first commit'
   git checkout -b links
   mkdir -p a/b
   echo hello > a/file_in_a
   ln -s ../file_in_a a/b/link_to_file_in_a
   git add a
   git commit -m 'Added symbolic link'

At this point, we have a valid, native symbolic link, which can be 
confirmed using notepad as before:
   notepad a/b/link_to_file_in_a

We run into problems, however, when we do the following:
   git checkout master && git checkout links

Git will create the symbolic link *before* it creates the target, and 
the result is a non-native file.  "notepad a/b/link_to_file_in_a" now 
produces "㰡祳汭湩㹫﻿../file_in_a ".

Shouldn't Cygwin honor "winsymlinks:native" even with the target does 
not exist?

I'm using Cygwin 6.1.

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