From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46829 invoked by alias); 25 Nov 2015 02:29:47 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 46820 invoked by uid 89); 25 Nov 2015 02:29:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: Ishtar.hs.tlinx.org Received: from ishtar.tlinx.org (HELO Ishtar.hs.tlinx.org) (173.164.175.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Nov 2015 02:29:46 +0000 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.9/8.14.4/SuSE Linux 0.8) with ESMTP id tAP2TdEp026066 for ; Tue, 24 Nov 2015 18:29:41 -0800 Message-ID: <56551D13.10907@tlinx.org> Date: Wed, 25 Nov 2015 03:20:00 -0000 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Symlink targets dereferenced when winsymlinks:native References: <564BAA1A.8000703@gmail.com> <20151118175503.GT6402@calimero.vinschen.de> In-Reply-To: <20151118175503.GT6402@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00391.txt.bz2 Corinna Vinschen wrote: >> If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. > > It matters. This is a bug in Cygwin, a missing test in fact. It should > never allow to create native symlinks to targets which only exist inside > of Cygwin. ---- Please don't. Why? It would be a built-in behavior difference between unix/linux symlinks and cygwin. symlink create on unix/linux doesn't look at the 'source' and create different types of links or different behaviors based on some ill-considered 'pathname filtering'. > Consider that /proc/self/fd has no meaning to non-Cygwin > processes at all. --- Unless you have a file-system driver, or a ".desktop.ini" in a windows created 'C:\Proc\.desktop.ini that redirects handlers for \proc to something similar. On my system, when I look at /proc/self/fd in cygwin+windows: cyg: /> ll /proc/self/fd total 0 lrwxrwxrwx 1 0 Nov 24 17:58 0 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 1 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 2 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 3 -> /proc/21920/fd/ win: /> cmd Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\>dir \proc\self\fd /w dir \proc\self\fd /w Volume in drive C is System Disk Volume Serial Number is E889-68E4 Directory of C:\proc\self\fd [.] [..] 0 File(s) 0 bytes 2 Dir(s) 401,855,094,784 bytes free ---- i.e. it shows a directory that is empty, and according to windows, was created over a year ago: C:\>dir |grep -i proc dir |grep -i proc 01/23/2014 05:13 PM proc As soon as you start prohibiting normal 'native' link creation based on some assumption about "who owns the path", I can't see how that won't end up biting you later. -- 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