It is known that cygwin has a naive interpretation for NTFS symlinks, by
translating those paths directly. This works fine with most cases, but
when you link stuffs under `/` to somewhere like `../cygwin/home`, it
simply breaks.

I have a directory tree like this:

|- cygwin/
  |- home/
    |- Arthur/
      |- .gnupg/ (mklink /D .gnupg \Users\Arthur\Appdata\Roaming\gnupg)
      |- .ssh/   (mklink /D .ssh \Users\Arthur\.ssh)
  |- tmp/
    |- 1.txt
|- cygwin64/
  |- tmp@  (mklink /D tmp ..\cygwin\tmp)
  |- home@ (mklink /D home ..\cygwin\home)

It appears that those `.gnupg` and `.ssh` with an absolute path to the
drive root was interpreted correctly, like
`/cygdrive/c/Users/Arthur/.ssh`, but cygwin64's /tmp and /home breaks,
with the following manner described:

1. Directly interacting with those paths, like attempting a `cd` into
them, cause 'File not found' errors. Running `ls --color` on them gives
a cyan color of it, but doesn't list their contents.
  1. `readlink -n /tmp` gives naively translated paths like
`../cygwin/tmp` which I believe what cygwin is using. Adding an extra
link like `ln -s /cygdrive/c/cygwin` fixes this, by making that
`/../cygwin` available.
  2. bash also does some startup checking and warns me about '/tmp missing'.
2. Operations like reading the contents of those directories are not
affected. For example, `cd` into `/home/Arthur` and running `cat` on
`/tmp/1.txt`. `ls` works, too.

-- 
Regards,
Arthur2e5