From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115877 invoked by alias); 11 Oct 2015 22:38:17 -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 115867 invoked by uid 89); 11 Oct 2015 22:38:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50,T_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; Sun, 11 Oct 2015 22:38:15 +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 t9BMc7Vr044454 for ; Sun, 11 Oct 2015 15:38:10 -0700 Message-ID: <561AE4CF.5030303@tlinx.org> Date: Sun, 11 Oct 2015 22:38:00 -0000 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Problems w/cygsym links vs. winsymlnks: (was Re: Running a program using a DLL under Cygwin) References: <22038.29093.221000.863384@woitok.gmail.com> <393201296.20151008181210@yandex.ru> <5619F993.1030703@tlinx.org> <2710156785.20151011172001@yandex.ru> In-Reply-To: <2710156785.20151011172001@yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00129.txt.bz2 Andrey Repin wrote: > Greetings, Linda Walsh! > >>>> I think symlink is a cygwin thing. Windows won't find that DLL (just >>>> like you won't find it using windows explorer.) >>> Unless he have created a Windows symlink, that is correct. >>> Explorer, however, may find it, as Cygwin symlinks are Windows LNK files. >> ---- >> Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native export' >> in your 'CYGWIN' env var at startup -- preferably in your Win profile. > >> However, cygwin occasionally has some bugs in how it creates links: >> /tmp> touch x >> /tmp> ln -s x y >> /tmp> ll x y >> -rw-rw-r--+ 1 0 Oct 10 22:27 x >> lrwxrwxrwx 1 6 Oct 10 22:28 y -> /tmp/x >> /tmp> cmd /c dir ?|grep '\s[xy]' >> 10/10/2015 10:32 PM 0 x >> 10/10/2015 10:40 PM y [C:\tmp\x] >> /tmp> rm y >> /tmp> mklink x y > > Do note that native mklink has arguments in the opposite order. (Microsoft...) --- Yes... but notice I typed that at a bash prompt and that it did the same thing as 'ln -s' and worked with the same order (mklink = bash-script that wraps around native mklink to make it same order). This also has mklink working but 'ln -s' changing a relative link to a absolute link Another example of cygwin's 'ln -s' chainging the link: --- /tmp> mkdir foo /tmp> ln -s foo cygfoo /tmp> mklink foo winfoo symbolic link created for winfoo <<===>> foo /tmp> cmd /c dir|grep foo 10/11/2015 11:23 AM cygfoo [C:\tmp\foo] 10/11/2015 11:22 AM foo 10/11/2015 11:24 AM winfoo [foo] --- looks innocent enough until I mv them: /tmp> mkdir links /tmp> mv foo cygfoo winfoo links /tmp> cd links /tmp/links> ls cygfoo@ foo/ winfoo@ /tmp/links> ll total 0 lrwxrwxrwx 1 8 Oct 11 11:23 cygfoo -> /tmp/foo drwxrwxr-x+ 1 0 Oct 11 11:22 foo/ lrwxrwxrwx 1 3 Oct 11 11:24 winfoo -> foo/ ----- Notice the cygwin created symlink points to a non-existing file /tmp/foo. A 3rd problem is trying to create the links before creating the dir. Not a problem on linux, but on windows, notice above, the symlinks to directories are a different type than the ones to regular files. So, currently the shell wrapper complains, but cygwin creates a cygwin-only symlink: a hidden 'System' file that windows can't use and normally doesn't see: /tmp/links> ln -s foo2 cygfoo2 /tmp/links> mklink foo2 winfoo2 Source, "foo2", does not exist. ### uhoh, "forgot" to create foo2 1st, better create it now: /tmp/links> mkdir foo2 /tmp/links> mklink foo2 winfoo2 /tmp/links> ls *?foo2 cygfoo2@ winfoo2@ /tmp/links> ll *?foo2 lrwxrwxrwx 1 4 Oct 11 12:31 cygfoo2 -> foo2/ lrwxrwxrwx 1 4 Oct 11 12:37 winfoo2 -> foo2/ ### create files in cygfoo2 and winfoo2 from cygwin: /tmp/links> touch {cyg,win}foo2/child_file /tmp/links> ll {cyg,win}foo2/child_file -rw-rw-r-- 1 0 Oct 11 13:22 cygfoo2/child_file -rw-rw-r-- 1 0 Oct 11 13:22 winfoo2/child_file ## so cygwin can create a child_file in each, but ## win's dir /a? ### looks like cygfoo2 is there, as seen on cygwin, above, but a ### dir cmd from win doesn't see it: /tmp/links> cmd /c dir|grep ' [AP]M' 10/11/2015 12:37 PM . 10/11/2015 12:37 PM .. 10/11/2015 11:23 AM cygfoo [C:\tmp\foo] 10/11/2015 11:22 AM foo 10/11/2015 12:35 PM foo2 10/11/2015 11:24 AM winfoo [foo] 10/11/2015 12:37 PM winfoo2 [foo2] ### attrib/no args shows files with attrs set: /tmp/links> attrib S C:\tmp\links\cygfoo2 ### dir /a will show also reveal hidden and system files: ### this shows diff of cygwin ln -s foo2 cygfoo2 ### and the bash-shell wrapper calling mklink ### (after 'mkdir foo2') /tmp/links> cmd /c dir /a *?foo2|grep ' [AP]M' 10/11/2015 12:31 PM 22 cygfoo2 10/11/2015 12:37 PM winfoo2 [foo2] ## creating files in 'cygfoo2 and winfoo2 > For the purposes of DLL loading, hardlink is probably a good choice. --- There is one drawback to hardlink usage (if softlink usage doesn't matter, of course, that's irrelevant). All copies of a hardlinked file will be locked if any of them are. Vs. if you use softlinks, -- the file they point to will likely be locked, by the symlinks might not be... if that's the case, symlinks could be repointed at new "dll"'s for fixes without requiring requiring the current dll's not be in use. -- 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