2.2.1: NTFS directory symlinks handling
Mingye Wang (Arthur2e5)
arthur2e5@aosc.xyz
Sat Aug 22 00:36:00 GMT 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150822/1e6d8669/attachment.sig>
More information about the Cygwin
mailing list