`CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

`CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

Hello everybody!

First post on this mailing list, my name is Gene, I'm from Russia,
long-time Linux user, but had to use Windows as desktop for the last 8
years. Cygwin really helps me to keep my sanity! Thanks :)

I have an issue to report:

Introduction: On a UNIX system, `ln -s target link` creates a link
regardless of target's existence.
This is used in some scripts, e.g. Gentoo's `run-crons` (which I also
use on Cygwin) uses a symlink pointing to the running process PID as
lockfile.
Issue: if `CYGWIN=winsymlinks:nativestrict` env var is set, running
`ln -s target link` completely fails (even though running `mklink link
target` in `cmd.exe` succeeds, same as `ln -s` does on UNIX). If
`CYGWIN=winsymlinks:native`, a non-native link is created.

So, `nativestrict` might break some (admittedly unorthodox) scripts.
With `native` these script work, but still a native link would be
preferrable and it is possible to create, but a non-native link is
created instead.

Bottom line, I think the native symlink creation code should be
checked and a possibility should be added to create links to
non-existent targets, rather than the current behavior of failing.

Thanks!
--Gene

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Andrey Repin]

Greetings, Gene Pavlovsky!

> I have an issue to report:

> Introduction: On a UNIX system, `ln -s target link` creates a link
> regardless of target's existence.
> This is used in some scripts, e.g. Gentoo's `run-crons` (which I also
> use on Cygwin) uses a symlink pointing to the running process PID as
> lockfile.
> Issue: if `CYGWIN=winsymlinks:nativestrict` env var is set, running
> `ln -s target link` completely fails (even though running `mklink link
> target` in `cmd.exe` succeeds, same as `ln -s` does on UNIX). If
> `CYGWIN=winsymlinks:native`, a non-native link is created.

> So, `nativestrict` might break some (admittedly unorthodox) scripts.
> With `native` these script work, but still a native link would be
> preferrable and it is possible to create, but a non-native link is
> created instead.

> Bottom line, I think the native symlink creation code should be
> checked and a possibility should be added to create links to
> non-existent targets, rather than the current behavior of failing.

This is actually an arguable behavior, even in Linux. I can imagine the
behavior is "undefined" in such a case.
But I'll leave final say to the more experienced members of the list.


-- 
With best regards,
Andrey Repin
Friday, April 29, 2016 01:55:21

Sorry for my terrible english...


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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On 04/28/2016 05:06 PM, Andrey Repin wrote:
>> Bottom line, I think the native symlink creation code should be
>> checked and a possibility should be added to create links to
>> non-existent targets, rather than the current behavior of failing.
> 
> This is actually an arguable behavior, even in Linux. I can imagine the
> behavior is "undefined" in such a case.

POSIX says a symlink to a missing target is perfectly well-defined (you
can't stat() through it, but you can readlink() it). But Windows native
symlinks can't do that.  So the problems you are encountering all stem
from the fact that you are trying to make Windows do something it can't.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Andrey Repin]

Greetings, Eric Blake!

> On 04/28/2016 05:06 PM, Andrey Repin wrote:
>>> Bottom line, I think the native symlink creation code should be
>>> checked and a possibility should be added to create links to
>>> non-existent targets, rather than the current behavior of failing.
>> 
>> This is actually an arguable behavior, even in Linux. I can imagine the
>> behavior is "undefined" in such a case.

> POSIX says a symlink to a missing target is perfectly well-defined (you
> can't stat() through it, but you can readlink() it). But Windows native
> symlinks can't do that.  So the problems you are encountering all stem
> from the fact that you are trying to make Windows do something it can't.

My initial reaction was that, too, but I tried mklink (CMD internal command)

  mklink x y

and it created the symlink in the empty directory just fine.


-- 
With best regards,
Andrey Repin
Friday, April 29, 2016 07:40:02

Sorry for my terrible english...


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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

I don't know if POSIX standard has something to say about that, but
here's a reference from GNU libc:

`man 2 symlink`:
>       A symbolic link (also known as a soft link) may point to an existing file or to a nonexistent one; the latter case is known as a dangling link.

On 29 April 2016 at 02:06, Andrey Repin <anrdaemon@yandex.ru> wrote:
> Greetings, Gene Pavlovsky!
>
>> I have an issue to report:
>
>> Introduction: On a UNIX system, `ln -s target link` creates a link
>> regardless of target's existence.
>> This is used in some scripts, e.g. Gentoo's `run-crons` (which I also
>> use on Cygwin) uses a symlink pointing to the running process PID as
>> lockfile.
>> Issue: if `CYGWIN=winsymlinks:nativestrict` env var is set, running
>> `ln -s target link` completely fails (even though running `mklink link
>> target` in `cmd.exe` succeeds, same as `ln -s` does on UNIX). If
>> `CYGWIN=winsymlinks:native`, a non-native link is created.
>
>> So, `nativestrict` might break some (admittedly unorthodox) scripts.
>> With `native` these script work, but still a native link would be
>> preferrable and it is possible to create, but a non-native link is
>> created instead.
>
>> Bottom line, I think the native symlink creation code should be
>> checked and a possibility should be added to create links to
>> non-existent targets, rather than the current behavior of failing.
>
> This is actually an arguable behavior, even in Linux. I can imagine the
> behavior is "undefined" in such a case.
> But I'll leave final say to the more experienced members of the list.
>
>
> --
> With best regards,
> Andrey Repin
> Friday, April 29, 2016 01:55:21
>
> Sorry for my terrible english...
>

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

The list of errors that might be returned by symlink(2) mention target
only 3 times:
       EFAULT target or linkpath points outside your accessible address space.
       ENAMETOOLONG
              target or linkpath was too long.
       ENOENT A directory component in linkpath does not exist or is a
dangling symbolic link, or target or linkpath is an empty string.

So my understanding is: target must be non-empty, not too long, and
don't point outside the accessible address space. Nothing about
existence.
--Gene


On 29 April 2016 at 03:05, Gene Pavlovsky <gene.pavlovsky@gmail.com> wrote:
> I don't know if POSIX standard has something to say about that, but
> here's a reference from GNU libc:
>
> `man 2 symlink`:
>>       A symbolic link (also known as a soft link) may point to an existing file or to a nonexistent one; the latter case is known as a dangling link.
>
> On 29 April 2016 at 02:06, Andrey Repin <anrdaemon@yandex.ru> wrote:
>> Greetings, Gene Pavlovsky!
>>
>>> I have an issue to report:
>>
>>> Introduction: On a UNIX system, `ln -s target link` creates a link
>>> regardless of target's existence.
>>> This is used in some scripts, e.g. Gentoo's `run-crons` (which I also
>>> use on Cygwin) uses a symlink pointing to the running process PID as
>>> lockfile.
>>> Issue: if `CYGWIN=winsymlinks:nativestrict` env var is set, running
>>> `ln -s target link` completely fails (even though running `mklink link
>>> target` in `cmd.exe` succeeds, same as `ln -s` does on UNIX). If
>>> `CYGWIN=winsymlinks:native`, a non-native link is created.
>>
>>> So, `nativestrict` might break some (admittedly unorthodox) scripts.
>>> With `native` these script work, but still a native link would be
>>> preferrable and it is possible to create, but a non-native link is
>>> created instead.
>>
>>> Bottom line, I think the native symlink creation code should be
>>> checked and a possibility should be added to create links to
>>> non-existent targets, rather than the current behavior of failing.
>>
>> This is actually an arguable behavior, even in Linux. I can imagine the
>> behavior is "undefined" in such a case.
>> But I'll leave final say to the more experienced members of the list.
>>
>>
>> --
>> With best regards,
>> Andrey Repin
>> Friday, April 29, 2016 01:55:21
>>
>> Sorry for my terrible english...
>>

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

> > POSIX says a symlink to a missing target is perfectly well-defined (you
> > can't stat() through it, but you can readlink() it). But Windows native
> > symlinks can't do that.  So the problems you are encountering all stem
> > from the fact that you are trying to make Windows do something it can't.
>
> My initial reaction was that, too, but I tried mklink (CMD internal command)
>
> > mklink x y
>
> and it created the symlink in the empty directory just fine.

This is my point exactly. Windows dangling symlinks can be created as
easily as in UNIX.
At least this is the case on my Win7 x64.

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Peter Rosin]

On 2016-04-29 13:34, Gene Pavlovsky wrote:
>>> POSIX says a symlink to a missing target is perfectly well-defined (you
>>> can't stat() through it, but you can readlink() it). But Windows native
>>> symlinks can't do that.  So the problems you are encountering all stem
>>> from the fact that you are trying to make Windows do something it can't.
>>
>> My initial reaction was that, too, but I tried mklink (CMD internal command)
>>
>>> mklink x y
>>
>> and it created the symlink in the empty directory just fine.
> 
> This is my point exactly. Windows dangling symlinks can be created as
> easily as in UNIX.
> At least this is the case on my Win7 x64.

No, it can't.

c:\>mklink a b
c:\>mkdir b
c:\>cd b
c:\b>cd ..
c:\>cd a
The directory name is invalid
c:\>rmdir b
c:\>echo hello > b
c:\>type a
hello

It only works for dangling links to files. Not good enough.

Cheers,
Peter

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

RE: [cygwin] Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Jason Pyeron]

> -----Original Message-----
> From: Peter Rosin
> Sent: Friday, April 29, 2016 8:03 AM
> 
> On 2016-04-29 13:34, Gene Pavlovsky wrote:
> >>> POSIX says a symlink to a missing target is perfectly 
> well-defined 
> >>> (you can't stat() through it, but you can readlink() it). But 
> >>> Windows native symlinks can't do that.  So the problems you are 
> >>> encountering all stem from the fact that you are trying 
> to make Windows do something it can't.
> >>
> >> My initial reaction was that, too, but I tried mklink (CMD 
> internal 
> >> command)
> >>
> >>> mklink x y
> >>
> >> and it created the symlink in the empty directory just fine.
> > 
> > This is my point exactly. Windows dangling symlinks can be 
> created as 
> > easily as in UNIX.
> > At least this is the case on my Win7 x64.
> 
> No, it can't.
> 
> c:\>mklink a b
> c:\>mkdir b
> c:\>cd b
> c:\b>cd ..
> c:\>cd a
> The directory name is invalid
> c:\>rmdir b
> c:\>echo hello > b
> c:\>type a
> hello
> 
> It only works for dangling links to files. Not good enough.

To be more precise, you must choose file or dir symlinks at cretion time:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>cd C:\cygwin\tmp\winlinktest\dirs

C:\cygwin\tmp\winlinktest\dirs>mklink /D a b
symbolic link created for a <<===>> b

C:\cygwin\tmp\winlinktest\dirs>mkdir b

C:\cygwin\tmp\winlinktest\dirs>cd b

C:\cygwin\tmp\winlinktest\dirs\b>cd ..

C:\cygwin\tmp\winlinktest\dirs>cd a

C:\cygwin\tmp\winlinktest\dirs\a>cd ..

C:\cygwin\tmp\winlinktest\dirs>rmdir b

C:\cygwin\tmp\winlinktest\dirs>echo hello > b

C:\cygwin\tmp\winlinktest\dirs>type a
Access is denied.

C:\cygwin\tmp\winlinktest\dirs>del b

C:\cygwin\tmp\winlinktest\dirs>mkdir b

C:\cygwin\tmp\winlinktest\dirs>cd a

C:\cygwin\tmp\winlinktest\dirs\a>

Jason Pyeron

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 



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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

I can confirm this behavior. Basically, mklink requires to choose file
(default) or directory (/D) link. It is true whether or not the target
exists (e.g. if your target is a directory,
/D is not implied automatically, you have to specify it). By contrast,
POSIX symlink doesn't distinguish file or directory symlinks.
So, what does it have to do with the topic exactly? According to your
logic, this is alos not good enough:

c:\>mkdir tmp

c:\>cd tmp

c:\tmp>mkdir target

c:\tmp>mklink /d link target
symbolic link created for link <<===>> target

c:\tmp>cd link

c:\tmp\link>cd ..

c:\tmp>rmdir target

c:\tmp>echo file >target

c:\tmp>cd link
The directory name is invalid.

c:\tmp>cat link
file

But it doesn't mean Cygwin should stop offering to use native symlinks
altogether, does it? What I mean is, POSIX symlinks are universal, and
NTFS symlinks are of two kinds. Using native symlinks, therefore, can
create potential problems, regardless of native or nativestrict mode.

I can see allowing dangling native symlinks can be a problem if
there's some script that creates some (dangling) symlinks, and then
later create some directories, to which the links are supposed to
point to, but since they didn't exist at link creation time, the links
are wrongfully of the file kind, and are not gonna work. I guess a
script like this can theoretically exist, even though it sounds quite
purposeless. Is this your concern? Then again, even crazier script can
exist, which creates a symlink pointing somewhere once, and then later
that somewhere can be removed and replaced with either a file or a
directory (sounds crazy and useless, but who knows? it's possible).
This script naturally will be broken whenever using native symlinks at
all.

I think some choice should be made here:
a) Allow creationg of dangling native symlinks (file by default).
b) Add a third native mode which is less strict than `nativestrict`,
but more strict than `native` - I'd like to use `nativestrict` on my
system, but due to this issue I have to use `native`.
c) Explicitly mention this behavior in Cygwin User Guide, so people
know that using `nativestrict` can break some scripts that rely on
creation of dangling symlinks. Currently the wording in CUG sounds
like it might fail because the filesystem doesn't support symlinks or
something.

Thanks.
--Gene


On 29 April 2016 at 15:02, Peter Rosin <peda@lysator.liu.se> wrote:
> On 2016-04-29 13:34, Gene Pavlovsky wrote:
>>>> POSIX says a symlink to a missing target is perfectly well-defined (you
>>>> can't stat() through it, but you can readlink() it). But Windows native
>>>> symlinks can't do that.  So the problems you are encountering all stem
>>>> from the fact that you are trying to make Windows do something it can't.
>>>
>>> My initial reaction was that, too, but I tried mklink (CMD internal command)
>>>
>>>> mklink x y
>>>
>>> and it created the symlink in the empty directory just fine.
>>
>> This is my point exactly. Windows dangling symlinks can be created as
>> easily as in UNIX.
>> At least this is the case on my Win7 x64.
>
> No, it can't.
>
> c:\>mklink a b
> c:\>mkdir b
> c:\>cd b
> c:\b>cd ..
> c:\>cd a
> The directory name is invalid
> c:\>rmdir b
> c:\>echo hello > b
> c:\>type a
> hello
>
> It only works for dangling links to files. Not good enough.
>
> Cheers,
> Peter

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Rinrin]

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

Hi Gene:
  I made a patch for my private use.
  First of all, you should setup `nativenocheck` in CYGWIN environment
variable to enable this feature.
  If the target does not exist, it will check the last digit of target
path, for '/' it will create a <SYMLINKD> instead of <SYMLINK>



在 2016/4/30 8:14, Gene Pavlovsky 写道:
> I can confirm this behavior. Basically, mklink requires to choose file
> (default) or directory (/D) link. It is true whether or not the target
> exists (e.g. if your target is a directory,
> /D is not implied automatically, you have to specify it). By contrast,
> POSIX symlink doesn't distinguish file or directory symlinks.
> So, what does it have to do with the topic exactly? According to your
> logic, this is alos not good enough:
> 
> c:\>mkdir tmp
> 
> c:\>cd tmp
> 
> c:\tmp>mkdir target
> 
> c:\tmp>mklink /d link target
> symbolic link created for link <<===>> target
> 
> c:\tmp>cd link
> 
> c:\tmp\link>cd ..
> 
> c:\tmp>rmdir target
> 
> c:\tmp>echo file >target
> 
> c:\tmp>cd link
> The directory name is invalid.
> 
> c:\tmp>cat link
> file
> 
> But it doesn't mean Cygwin should stop offering to use native symlinks
> altogether, does it? What I mean is, POSIX symlinks are universal, and
> NTFS symlinks are of two kinds. Using native symlinks, therefore, can
> create potential problems, regardless of native or nativestrict mode.
> 
> I can see allowing dangling native symlinks can be a problem if
> there's some script that creates some (dangling) symlinks, and then
> later create some directories, to which the links are supposed to
> point to, but since they didn't exist at link creation time, the links
> are wrongfully of the file kind, and are not gonna work. I guess a
> script like this can theoretically exist, even though it sounds quite
> purposeless. Is this your concern? Then again, even crazier script can
> exist, which creates a symlink pointing somewhere once, and then later
> that somewhere can be removed and replaced with either a file or a
> directory (sounds crazy and useless, but who knows? it's possible).
> This script naturally will be broken whenever using native symlinks at
> all.
> 
> I think some choice should be made here:
> a) Allow creationg of dangling native symlinks (file by default).
> b) Add a third native mode which is less strict than `nativestrict`,
> but more strict than `native` - I'd like to use `nativestrict` on my
> system, but due to this issue I have to use `native`.
> c) Explicitly mention this behavior in Cygwin User Guide, so people
> know that using `nativestrict` can break some scripts that rely on
> creation of dangling symlinks. Currently the wording in CUG sounds
> like it might fail because the filesystem doesn't support symlinks or
> something.
> 
> Thanks.
> --Gene
> 
> 
> On 29 April 2016 at 15:02, Peter Rosin <peda@lysator.liu.se> wrote:
>> On 2016-04-29 13:34, Gene Pavlovsky wrote:
>>>>> POSIX says a symlink to a missing target is perfectly well-defined (you
>>>>> can't stat() through it, but you can readlink() it). But Windows native
>>>>> symlinks can't do that.  So the problems you are encountering all stem
>>>>> from the fact that you are trying to make Windows do something it can't.
>>>>
>>>> My initial reaction was that, too, but I tried mklink (CMD internal command)
>>>>
>>>>> mklink x y
>>>>
>>>> and it created the symlink in the empty directory just fine.
>>>
>>> This is my point exactly. Windows dangling symlinks can be created as
>>> easily as in UNIX.
>>> At least this is the case on my Win7 x64.
>>
>> No, it can't.
>>
>> c:\>mklink a b
>> c:\>mkdir b
>> c:\>cd b
>> c:\b>cd ..
>> c:\>cd a
>> The directory name is invalid
>> c:\>rmdir b
>> c:\>echo hello > b
>> c:\>type a
>> hello
>>
>> It only works for dangling links to files. Not good enough.
>>
>> Cheers,
>> Peter
> 
> --
> 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
> 


[-- Attachment #2: 0005-native-symlinks-non-exist-target-support.patch --]
[-- Type: application/x-itunes-itlp, Size: 4103 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Marco Atzeri]

On 05/10/2016 05:00, Rinrin wrote:
> Hi Gene:
>   I made a patch for my private use.
>   First of all, you should setup `nativenocheck` in CYGWIN environment
> variable to enable this feature.
>   If the target does not exist, it will check the last digit of target
> path, for '/' it will create a <SYMLINKD> instead of <SYMLINK>
>
>

BOTTOM POST on this list
please

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

On 5 October 2016 at 06:00, Rinrin <rinrin@imbrian.org> wrote:
> Hi Gene:
>   I made a patch for my private use.
>   First of all, you should setup `nativenocheck` in CYGWIN environment
> variable to enable this feature.
>   If the target does not exist, it will check the last digit of target
> path, for '/' it will create a <SYMLINKD> instead of <SYMLINK>

Hi Rinrin.
I'd like to try it out, is your patch included in mainline Cygwin?
If not, how can I get a version with that patch?
Thanks.
--Gene

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Rinrin]

在 2016/10/6 18:14, Gene Pavlovsky 写道:
> On 5 October 2016 at 06:00, Rinrin <rinrin@imbrian.org> wrote:
>> Hi Gene:
>>   I made a patch for my private use.
>>   First of all, you should setup `nativenocheck` in CYGWIN environment
>> variable to enable this feature.
>>   If the target does not exist, it will check the last digit of target
>> path, for '/' it will create a <SYMLINKD> instead of <SYMLINK>
> 
> Hi Rinrin.
> I'd like to try it out, is your patch included in mainline Cygwin?
> If not, how can I get a version with that patch?
> Thanks.
> --Gene
I posted compiled version here.
http://www.megafileupload.com/kgm0/cygwin1.zip

This version contains another patch ripped from msys.
When cygwin process call non-cygwin executable, like mingw binary,
it will translate cygwin path format to windows format.

For example:
/mingw64/usr/bin $ iconv --help
Usage: C:\Portable\PrivData\cygwin\mingw64\usr\bin\iconv.exe [OPTION...]
[-f ENCODING] [-t ENCODING] [INPUTFILE...]
or:    C:\Portable\PrivData\cygwin\mingw64\usr\bin\iconv.exe -l

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

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Gene Pavlovsky]

Hey, sounds cool.
Did you submit your patch to Cygwin devs? Are there plans for accepting it?


On 7 October 2016 at 05:06, Rinrin <rinrin@imbrian.org> wrote:
> 在 2016/10/6 18:14, Gene Pavlovsky 写道:
>> On 5 October 2016 at 06:00, Rinrin <rinrin@imbrian.org> wrote:
>>> Hi Gene:
>>>   I made a patch for my private use.
>>>   First of all, you should setup `nativenocheck` in CYGWIN environment
>>> variable to enable this feature.
>>>   If the target does not exist, it will check the last digit of target
>>> path, for '/' it will create a <SYMLINKD> instead of <SYMLINK>
>>
>> Hi Rinrin.
>> I'd like to try it out, is your patch included in mainline Cygwin?
>> If not, how can I get a version with that patch?
>> Thanks.
>> --Gene
> I posted compiled version here.
> http://www.megafileupload.com/kgm0/cygwin1.zip
>
> This version contains another patch ripped from msys.
> When cygwin process call non-cygwin executable, like mingw binary,
> it will translate cygwin path format to windows format.
>
> For example:
> /mingw64/usr/bin $ iconv --help
> Usage: C:\Portable\PrivData\cygwin\mingw64\usr\bin\iconv.exe [OPTION...]
> [-f ENCODING] [-t ENCODING] [INPUTFILE...]
> or:    C:\Portable\PrivData\cygwin\mingw64\usr\bin\iconv.exe -l
>
> --
> 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
>

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