Author steve.dower
Recipients eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2019-08-21.20:08:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1566418131.32.0.222415082656.issue37834@roundup.psfhosted.org>
In-reply-to
Content
So my colleagues confirmed that they deliberately represent junction points as symlinks within WSL, including translating the target to the mounted location (assuming it is mounted) and letting the Linux code traverse it normally. They also said they haven't heard any feedback suggesting it causes any trouble.

However, the more I've thought about the implications of islink() returning true for a junction, the more I've come around to Eryk's point of view, so I'm going to merge this as is (the PR currently only sets S_IFLNK for actual symlinks).

That said, nt.readlink() will still be able to read the target of a junction, and code like I have in PR 15287 that uses readlink() to follow links will resolve them (noting that that implementation of realpath() attempts to let the OS follow it first). I think that covers the intended use cases best.

The only updates left are a couple of docs here, but I'll finish up issue9949 first and rebase on those changes as well.
History
Date User Action Args
2019-08-21 20:08:51steve.dowersetrecipients: + steve.dower, paul.moore, tim.golden, zach.ware, eryksun
2019-08-21 20:08:51steve.dowersetmessageid: <1566418131.32.0.222415082656.issue37834@roundup.psfhosted.org>
2019-08-21 20:08:51steve.dowerlinkissue37834 messages
2019-08-21 20:08:50steve.dowercreate