From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19198 invoked by alias); 3 Apr 2013 21:31:42 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 19185 invoked by uid 89); 3 Apr 2013 21:31:41 -0000 X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from st11p02mm-asmtpout004.mac.com (HELO st11p02mm-asmtp004.mac.com) (17.172.220.239) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 03 Apr 2013 21:31:39 +0000 Received: from bubba.internal.markzware.com (174-127-1-50.static-ip.telepacific.net [174.127.1.50]) by st11p02mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MKP0065A7SLHR80@st11p02mm-asmtp004.mac.com> for cygwin-developers@cygwin.com; Wed, 03 Apr 2013 21:31:35 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-03_07:2013-04-03,2013-04-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1304030226 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: native symlink From: James Gregurich In-reply-to: <20130403152907.GD2468@calimero.vinschen.de> Date: Wed, 03 Apr 2013 21:31:00 -0000 Content-transfer-encoding: quoted-printable Message-id: References: <80C3E267-F369-4FF3-A3FD-69A997FFC33B@mac.com> <5153759A.7080307@cygwin.com> <79518574-72AB-451F-ACE3-3277981987D5@mac.com> <20130401195216.GA7174@ednor.casa.cgf.cx> <9A868E84-96C2-486C-98DF-3FF5079ACD50@mac.com> <20130402000633.GA3977@ednor.casa.cgf.cx> <9362C76C-DB6B-4DA8-B61E-7980CFDF7A8A@mac.com> <20130403014056.GA3383@ednor.casa.cgf.cx> <2EC5409B-C507-4B41-862C-D42D69CE3741@mac.com> <515BB10C.9080101@openafs.org> <20130403152907.GD2468@calimero.vinschen.de> To: cygwin-developers@cygwin.com X-SW-Source: 2013-04/txt/msg00044.txt.bz2 On Apr 3, 2013, at 8:29 AM, Corinna Vinschen wrote: >=20 >=20 > There are some downsides to native symlinks which make them hard to > justify, if not downright useless in a POSIX environment. >=20 We all understand the limitations and we grant you that. That is why I have= proposed an add-on feature rather than an augmentation of the symlink() fu= nction. Add an additional API call in the spirit of existing functions such= as cygwin_conv_path_list() that will allow an existing cygwin symlink to b= e replaced by a native symlink. Those who need native symlinks can use that= function call. As an add-on, optional API call, he function can accept fla= gs that allow the user to choose how to handle non-optimal situations such = as relative paths that exceed PATH_MAX, and it can return error codes that = indicate exactly why a native symlink failed to be produced. This way, the= re is no ambiguity that can generate support tickets. >> As I see it, as flawed as Microsoft Symlinks are they are the common >> interface that enables mixed applications to communicate with one >> another. As such, where they can be used, they should be used. What is >> the point of cross-platform support if mixed platform applications >> cannot transparently share the data? >=20 > Cygwin is a POSIX environment in the first place. Interop is fine, > but if it collides with POSIX, we're clearly favoring POSIX. I'm suggesting an approach that does not conflict with posix. However, I do= n't know if that concept works for Jeffery or not.=20 > Having said that. >=20 > Chris and I had a private discussion (not the first one on the subject!) > and we're willing to revisit the use of native symlinks in Cygwin but > it will be a while before that happens. A change to the path handling > code like this is not something that we'd consider for 1.7.18 which is > long overdue anyway. fair enough. If its on the radar, I'm happy. What I have should be function= al for a long time. Like I said, I can contribute my code that you can use = as a guide. >=20 > What I will do is to add a new CYGWIN environment variable option, along > the lines of the winsymlinks option(*), or, which is very likely the > more elgant solution, a mount option, which will result in trying to > create native symlinks first, and a Cygwin symlink only if creating > a native symlink failed. That should help you along. If you want to go all the way, that works for me too.