Re: Cygwin Dirmngr and TBB for windows

[Corinna Vinschen]

On Aug 30 21:20, john doe wrote:
> On 8/30/2018 5:07 PM, Corinna Vinschen wrote:
> > On Aug 30 14:35, Marco Atzeri wrote:
> > > Am 30.08.2018 um 11:30 schrieb john doe:
> > > > On 7/11/2018 10:11 AM, john doe wrote:
> > > > > Hi,
> > > > > 
> > > > > I'm trying to get Cygwin dirmngr to work with  Tor Browser for 
> > > > > Windows.
> > > > > 
> > > > > Following some discussion on the gnupg user list it looks like that
> > > > > the connect(2) function in Cygwin does not return the proper error
> > > > > code:
> > > > > 
> > > > > https://lists.gnupg.org/pipermail/gnupg-users/2018-July/060768.html
> > > > > 
> > > > > On the above link one of the dev suggest that connect(2) returns
> > > > > EPERMS instead of ECONREFUSED.
> > > > > 
> > > > > If ECONREFUSED is not returned when port 9050 is queried the
> > > > > fallback code in dirmngr will not be executed and port 9150 will
> > > > > never be used.
> > > > > 
> > > > > Using dirmngr on Debian with TBBfor linux works as expected.
> > > > > 
> > > > > Can anyone confirm that and subcequently make Cygwin return the
> > > > > proper error code?
> > > > > 
> > > > > Any help is appriciated.
> > > > > 
> > > > 
> > > > As any one has been able to confirm that the issue is present in Cygwin
> > > > code?
> > > > I didn't see anything regarding this issue in the beta version of Cygwin
> > > > or did I mist it?
> > > 
> > > 
> > > a Simple Test Case will help to verify the claim.
> > 
> > Full ACK.
> > 
> > > connect is not expected to return EPERM
> > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html
> > 
> > Cygwin does not explicitely generate EPERM anywhere near
> > AF_INET/AF_INET6 code.  Nor does a Winsock error exist which
> > gets gonverted to EPERM.
> > 
> > The *only* way to generate EPERM is if an underlying Winsock function
> > returns an error code not handled by Cygwin.  I never encountered
> > that case, though.  Thus, a STC is highly appreciated.
> > 
> > 
> > Corinna
> > 
> 
> Thanks both for your answer and your willingness to look into this.
> 
> STC:
> 1)  Have Tor Browser for Windows up and running.
> 2)  Start dirmngr:
>   $ mkdir ${HOME}/try
>   $ dirmngr --homedir ${HOME}/try -vvv --debug-all --server --use-tor
>   -> KS_GET -- 0x6C6ACD6417B3ACB1

That's not a STC.  STC means a simple, self-contained piece of (ideally)
C code to reproduce the issue.  I simply don't have the time to hunt
down something in lots of foreign code.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: error in "cygpath" behavior

[Corinna Vinschen]

On Aug 30 21:37, Steven Penny wrote:
> It is my understanding that given relative input, "cygpath" shall produce
> relative output unless given "-a" option. However I noticed a discrepancy. 
> These
> are all correct:
> 
>$ cygpath .
>.
> 
>$ cygpath ..
>..
> 
>$ cygpath -w .
>.
> 
> This is not:
> 
>$ cygpath -w ..
>C:\cygwin64\home\

Long-standing behaviour.  ".." in Cygwin and ".." in Windows can totally
disagree.  The path is always convert to absolute at this point in favor
of correct output.  There's also the additional restriction (though
not in this case) that relative Windows paths must not be longer than
MAX_PATH (260) chars.

I'm certainly open to patches to the underlying cygwin_conv_path
function to change the Windows path to relative if possible.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[ANNOUNCEMENT] Updated: gnupg2-2.2.10-1

[Marco Atzeri]

Version  2.2.10-1  of

gnupg2

is available in the Cygwin distribution:

CHANGES
Latest upstream security fix release
https://lists.gnupg.org/pipermail/gnupg-announce/2018q3/000428.html

DESCRIPTION
The GNU Privacy Guard

GnuPG is a command line tool without any graphical user interface.
It is an universal crypto engine which can be used directly from
a command line prompt, from shell scripts, or from other programs.
Therefore GnuPG is often used as the actual crypto backend of other
applications.


Full OpenPGP implementation (see RFC4880 at RFC Editor).
Full CMS/X.509 (S/MIME) implementation.
Ssh-agent implementation
Runs on all Unix platforms, Windows and macOS.
A full replacement of PGP; written from scratch.
Does not use any patented algorithms.
Freely available under the GPL;
Can be used as a filter program.
Better functionality than PGP with state of the art security features.
Decrypts and verifies PGP 5, 6 and 7 messages.
Supports RSA, ECDH, ECDSA, EdDSA, Elgamal, DSA, AES, Camellia, 
3DES, Twofish, SHA2, and many more algorithms.

Language support for a load of languages.
Online help system.
Optional anonymous message receivers.
Integrated support for HKP keyservers (sks-keyservers.net).
and many more things….

HOMEPAGE
http://www.gnupg.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

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

[ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin release 2.11.0-1.

===

What's new:
---

- New APIs: clearenv, pthread_tryjoin_np, pthread_timedjoin_np,
  sched_getcpu.

- New APIs: aio_cancel, aio_error, aio_fsync, aio_read, aio_return,
  aio_suspend, aio_write, lio_listio.
  New header: .


What changed:
-

- SO_RCVTIMEO and SO_SNDTIMEO socket options are now honored.

- /proc/cpuinfo now reports L3 cache size on Intel CPUs.

- Drop denormal-operand exception from FE_ALL_EXCEPT, as on Linux.

- Rename the --file option of setfacl(1) to --set-file, as on Linux.

- Support Unicode 10.

- Following glibc, `union wait' has now been removed.  Applications
  using union wait and these macros will have to migrate to the
  POSIX-specified int status type.


Bug Fixes
-

- Fix utils path handling in case cygdrive path is just '/'.
  Addresses: https://cygwin.com/ml/cygwin/2018-02/msg00174.html

- Fix a potential SIGFPE in strtod, if FE_INVALID exceptions are
  enabled.
  Addresses: https://cygwin.com/ml/cygwin/2018-04/msg00055.html

- Fix a CPU affinity problem when creating /proc/cpuinfo output.
  Addresses: https://cygwin.com/ml/cygwin/2018-04/msg00118.html

- Fix a buffer underrun problem in Win32 path normalization.
  Addresses: https://cygwin.com/ml/cygwin/2018-05//msg00017.html

- Fix a stack alignment problem which may lead to spurious crashes after
  fork.
  Addresses: https://cygwin.com/ml/cygwin-patches/2018-q2/msg00016.html

- Fix a g++ compilation problem with -std=c++14 or -std=c++17.
  Addresses: https://cygwin.com/ml/cygwin/2018-05/msg00316.html

- Fix FPE flag handling for division by zero conditions
  Addresses: https://cygwin.com/ml/cygwin/2018-06/msg00281.html

- Fix Unicode table.
  Addresses: https://cygwin.com/ml/cygwin/2018-06/msg00248.html

- Handle a non-standard return value from some tape drives to
  report a "no-media" error.
  Addresses: https://cygwin.com/ml/cygwin/2018-06/msg00245.html

- Fix duration handling in sigtimedwait
  Addresses: https://cygwin.com/ml/cygwin-patches/2018-q3/msg00018.html

- Make FP environment symbols available on x86_64.
  Addresses: https://cygwin.com/ml/cygwin/2018-07/msg00183.html

- Fix fegetenv behaviour.
  Addresses: https://cygwin.com/ml/cygwin/2018-08/msg0.html

- Fix NaN handling in strtof/strtod/strtold.
  Addresses: https://cygwin.com/ml/cygwin/2018-08/msg00150.html

- Fix memory allocation values in /proc//status and /proc//statm.
  Addresses: https://cygwin.com/ml/cygwin/2018-08/msg00223.html

- Fix handling of unknown accounts in file ACLs.  Add name->SID
  conversion for (most) self-constructed account names.
  Addresses: https://cygwin.com/ml/cygwin/2018-08/msg00295.html

- Correctly handle Logon Session accounts on Windows 10.
  Addresses: Found during debugging

===


Have fun,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

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

[ANNOUNCEMENT] [SECURITY] stunnel-5.48-1

[Andrew Schulman]

stunnel 5.48-1 is now available in Cygwin. This is a new upstream release,
with a security bug fix:

* Fixed requesting client certificate when specified as a global option.

as well as other bug fixes and minor enhancements since the previous Cygwin
release, version 5.46-1. You can read the upstream changelog at
https://www.stunnel.org/sdf_ChangeLog.html.

stunnel is a program that allows you to encrypt arbitrary TCP connections
inside SSL (Secure Sockets Layer). stunnel can allow you to secure non-SSL
aware daemons and protocols (like POP, IMAP, LDAP, etc) by having stunnel
provide the encryption, requiring no changes to the daemon's code.

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com

If you need more information on unsubscribing, start reading here: 

http://cygwin.com/lists.html#subscribe-unsubscribe

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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 Dirmngr and TBB for windows

[Brian Inglis]

On 2018-08-31 02:34, Corinna Vinschen wrote:
> On Aug 30 21:20, john doe wrote:
>> On 8/30/2018 5:07 PM, Corinna Vinschen wrote:
>>> On Aug 30 14:35, Marco Atzeri wrote:
 Am 30.08.2018 um 11:30 schrieb john doe:
> On 7/11/2018 10:11 AM, john doe wrote:
>> I'm trying to get Cygwin dirmngr to work with  Tor Browser for Windows.
>> Following some discussion on the gnupg user list it looks like that
>> the connect(2) function in Cygwin does not return the proper error
>> code:
>> https://lists.gnupg.org/pipermail/gnupg-users/2018-July/060768.html
>> On the above link one of the dev suggest that connect(2) returns
>> EPERMS instead of ECONREFUSED.
>> If ECONREFUSED is not returned when port 9050 is queried the
>> fallback code in dirmngr will not be executed and port 9150 will
>> never be used.
>> Using dirmngr on Debian with TBB for linux works as expected.
>> Can anyone confirm that and subsequently make Cygwin return the
>> proper error code?
>> Any help is appriciated.
> Has any one has been able to confirm that the issue is present in Cygwin
> code?
> I didn't see anything regarding this issue in the beta version of Cygwin
> or did I miss it?
 a Simple Test Case will help to verify the claim.
>>> Full ACK.
 connect is not expected to return EPERM
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html
>>> Cygwin does not explicitely generate EPERM anywhere near AF_INET/AF_INET6
>>> code. Nor does a Winsock error exist which gets gonverted to EPERM.
>>> The *only* way to generate EPERM is if an underlying Winsock function 
>>> returns an error code not handled by Cygwin. I never encountered that
>>> case, though. Thus, a STC is highly appreciated.
>> Thanks both for your answer and your willingness to look into this.
>> STC:
>> 1) Have Tor Browser for Windows up and running.
>> 2) Start dirmngr:
>> $ mkdir ${HOME}/try
>> $ dirmngr --homedir ${HOME}/try -vvv --debug-all --server --use-tor
>> -> KS_GET -- 0x6C6ACD6417B3ACB1
> That's not a STC. STC means a simple, self-contained piece of (ideally)
> C code to reproduce the issue. I simply don't have the time to hunt
> down something in lots of foreign code.

We may be able to run most Windows console apps interoperating with Cygwin
console apps, but with some Windows GUI apps about all we may be able to do is
launch them with cygstart: trying to integrate a security related app based on
an old release of an app designed for another platform offers too many
opportunities for mismatches.

As the OP has Debian TBB and dirmngr, why not use them, maybe from Cygwin/X?
Or the OP could install and run GNU PG/2 for Windows with TBB for Windows so the
apps would be working on the same basis and making the same assumptions about
paths, certs, IPC, perms, and errors.

Alternatively the OP could try building the Tor Browser from source to run under
Cygwin/X for use with Cygwin dirmngr, although as Tor is based on (old) Firefox,
and that is not available under Cygwin/X, and available browsers tend to be
lightweights, there may be too many porting issues from embedded Unix and
Windows assumptions to make that feasible, as I'm sure someone has (or maybe a
few have) tried that.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: error in "cygpath" behavior

[cyg Simple]

On 8/31/2018 4:57 AM, Corinna Vinschen wrote:
> On Aug 30 21:37, Steven Penny wrote:
>> It is my understanding that given relative input, "cygpath" shall produce
>> relative output unless given "-a" option. However I noticed a discrepancy. 
>> These
>> are all correct:
>>
>>$ cygpath .
>>.
>>
>>$ cygpath ..
>>..
>>
>>$ cygpath -w .
>>.
>>
>> This is not:
>>
>>$ cygpath -w ..
>>C:\cygwin64\home\
> 
> Long-standing behaviour.  ".." in Cygwin and ".." in Windows can totally
> disagree.  The path is always convert to absolute at this point in favor
> of correct output.  There's also the additional restriction (though
> not in this case) that relative Windows paths must not be longer than
> MAX_PATH (260) chars.
> 
> I'm certainly open to patches to the underlying cygwin_conv_path
> function to change the Windows path to relative if possible.

Don't forget the possibility that '..' points to a symlink which Windows
will not understand.

$ mkdir -p /foo/baz
$ ln -s /foo /bar
$ cd /bar/baz
$ cygpath -w ..

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

Re: error in "cygpath" behavior

[Eric Blake]

On 08/31/2018 02:48 PM, cyg Simple wrote:



Don't forget the possibility that '..' points to a symlink which Windows
will not understand.

$ mkdir -p /foo/baz
$ ln -s /foo /bar
$ cd /bar/baz
$ cygpath -w ..


Except .. never points to a symlink.  It always points to the physical 
directory that contains the current directory (that is, /foo, not /bar). 
 The shell can maintain a notion of a logical current directory (based 
on whether you use 'set -P' for physical or 'set +P' for logical; where 
bash defaults to +P), and in that mode, 'cd ..' behaves logically 
(acting as though you are now in /bar, rather than actually changing you 
to /foo).  But that still doesn't change the fact that '..' in file name 
resolution never resolves to a symlink, because the shell is merely 
rewriting your ".." to avoid passing it on to the syscalls, rather than 
the syscalls actually knowing about logical mode.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

--
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: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

[tlake]

After running setup (64 bit) I still have version 2.10. I even tried 
uninstalling and running setup again.

Tom L
-Original Message-
From: Corinna Vinschen  
Sent: Friday, August 31, 2018 11:21 AM
To: cygwin@cygwin.com
Subject: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

Hi folks,


I uploaded a new Cygwin release 2.11.0-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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.11.0-1

[Marco Atzeri]

Am 31.08.2018 um 22:31 schrieb tl...@twcny.rr.com:

After running setup (64 bit) I still have version 2.10. I even tried 
uninstalling and running setup again.

Tom L



have you stopped all processes including services before the update ?

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: error in "cygpath" behavior

[Steven Penny]

On Fri, 31 Aug 2018 10:57:34, Corinna Vinschen wrote:

Long-standing behaviour.  ".." in Cygwin and ".." in Windows can totally
disagree.  The path is always convert to absolute at this point in favor
of correct output.  There's also the additional restriction (though
not in this case) that relative Windows paths must not be longer than
MAX_PATH (260) chars.

I'm certainly open to patches to the underlying cygwin_conv_path
function to change the Windows path to relative if possible.


I am not understanding - it appears that "dot-dot" (..) is well defined by
POSIX:


The special filename dot-dot shall refer to the parent directory of its
predecessor directory. As a special case, in the root directory, dot-dot may
refer to the root directory itself.


http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13

so it would appears that ".." would be an acceptable return value in any case.


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

Bug Report: Regression in Cygwin 2.11.0-1

[Bryan Phelps]

Hello,


Thank you for all the work on Cygwin! I've been using it to spin up an 
environment to build the OCaml compiler / toolchain, and it was working great.


However, today, all our CI builds mysteriously started failing - at first, I 
suspected it was a problem with AppVeyor, but I also failures with VSTS. We use 
an NPM package (`esy-bash`) to spin up a Cygwin environment, and then use that 
to build the OCaml toolchain.


The error message we started receiving today is:

OCAML_FLEXLINK="../boot/ocamlrun ../flexdll/flexlink.exe" ../byterun/ocamlrun 
../ocamlc -g -nostdlib -I ../utils -I ../parsing -I ../stdlib -I 
../compilerlibs -strict-sequence -safe-string -strict-formats -w 
+a-4-9-41-42-44-45-48 -warn-error A -custom ocamlcommon.cma -o ocamltest.exe 
run_win32.o run_stubs.o ocamltest_config.cmo testlib.cmo run_command.cmo 
filetype.cmo filecompare.cmo backends.cmo variables.cmo environments.cmo 
builtin_variables.cmo builtin_modifiers.cmo actions.cmo builtin_actions.cmo 
tests.cmo builtin_tests.cmo tsl_ast.cmo tsl_parser.cmo tsl_lexer.cmo 
tsl_semantics.cmo options.cmo main.cmo
x86_64-w64-mingw32-gcc: error: ../stdlib\libcamlrun.a: No such file or directory


The complete build log is here:

https://gist.github.com/bryphe/58603ab752ecd988f78ee383fa9c9e78


After some investigation, I was able to isolate the issue - environments with 
the 2.10.0-1 version of Cygwin built successfully, whereas newer environments 
with the 2.11.0-1 version exhibit this failure. The remaining packages are in 
parity - importantly, all the mingw packages we install are at the same version.


Results of cygcheck -c on both environments:

- Working environment: 
https://gist.github.com/bryphe/b11f72f60d9d7c04a8e709e6a8eb20ff

- Failing environment: 
https://gist.github.com/bryphe/7cf4e6216030781eb273ac45d36590cd


I'll continue to look around for a more minimal repro, but I suspect there may 
be other manifestations of it. It looks like there were a few path-related 
patches that came in to 2.11.0-1, so perhaps this scenario was impacted.


In the meantime - is there a way we can pin the cygwin package to the 2.10.0-1 
version, to unblock our builds?


Thank you!

Bryan



Sent from Outlook

--
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: error in "cygpath" behavior

[Achim Gratz]

Steven Penny writes:
> I am not understanding - it appears that "dot-dot" (..) is well defined by
> POSIX:
[…]
> so it would appears that ".." would be an acceptable return value in any case.

Except that you've asked for a Windows path, not POSIX, and you have no
idea what Windows' idea of the CWD is once you start using that string
with a Windows application.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: error in "cygpath" behavior

[Brian Inglis]

On 2018-08-31 16:34, Steven Penny wrote:
> On Fri, 31 Aug 2018 10:57:34, Corinna Vinschen wrote:
>> Long-standing behaviour.  ".." in Cygwin and ".." in Windows can totally
>> disagree.  The path is always convert to absolute at this point in favor
>> of correct output.  There's also the additional restriction (though
>> not in this case) that relative Windows paths must not be longer than
>> MAX_PATH (260) chars.
>> I'm certainly open to patches to the underlying cygwin_conv_path
>> function to change the Windows path to relative if possible.
> I am not understanding - it appears that "dot-dot" (..) is well defined by
> POSIX:
>> The special filename dot-dot shall refer to the parent directory of its
>> predecessor directory. As a special case, in the root directory, dot-dot may
>> refer to the root directory itself.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
> so it would appears that ".." would be an acceptable return value in any case.

See Eric Blake's response to other poster.
Proc FS entry /proc/self/cwd only links to the current working directory, and
may/does? not necessarily reflect the logical or physical path taken by cd to
get to the current directory: only the current shell tracks the logical or
physical path taken by cd to get to the current directory, and can interpret to
which directory .. refers.
If /proc/self/cwd tracked all processes' logical or physical paths taken by
chdir(2) to get to the current directory, that link might be used to resolve ..
unambiguously. Quoting Corinna: "PGA" ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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