$ | >

Use interoperable NTFS symlinks in DrvFS when possible

From recent blog post I understand a new type of reparse point was introduced to support symlinks. This new reparse point type is not understood by windows.

If instead this type was only used when necessary (e.g. symlinks to devices) and interoperable types used for the more common file/directory symlinks a significant barrier would be removed.

Bypassing the traditional access restrictions on symlink creation does not seem like an unreasonable risk given the target userbase.

115 votes
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Neville Bagnall shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

3 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • nomike commented  ·   ·  Flag as inappropriate

    This is also a feature I highly would like to see as it's hard at the moment to interchangeably work on a git checkout with symlinks from win32 and wsl based tools.

  • David Noble commented  ·   ·  Flag as inappropriate

    We need interoperable symlinks. I would leave the interop mechanism to the engineers. It does, however, seem fitting to use the native symlink format on each file system. It also sees fitting that any subsystem should be able to read and make sense of the attributes on any other subsystem's files.

  • Daniel Llewellyn commented  ·   ·  Flag as inappropriate

    I think the better option is to wait until Windows can access the WSL filesystem per another ask, respecting permissions etc, and when that is done add support into Win32 to understand the new reparse point.

    That is add support to Win32 for WSL's format; do NOT make WSL use the original NTFS junctions. That way the linux extras enabled by the new reparse format can be maintained rather than trying to shoehorn it into an incompatible junction.

Feedback and Knowledge Base