NTFS volume on Linux - junction does not work properly

[jeffbi]

Manifestations:

1. DirectoryInfo.Attributes does not include ReparsePoint
2. DirectoryInfo.Delete fails - see dotnet/corefx#17844

Given this directory structure on an NTFS volume

E:.
+---sub
|   |   sym-to-other
|   |
|   +---junction-to-other
|   |
|   \---symd-to-other
|
\---sub_other

running dir from the Windows command line shows

04/02/2017  05:27 PM    <JUNCTION>     junction-to-other [\??\E:\link-test\sub_other]
04/02/2017  05:27 PM    <SYMLINK>      sym-to-other [E:\link-test\sub_other]
04/02/2017  05:27 PM    <SYMLINKD>     symd-to-other [..\sub_other]

Moving the NTFS device to a Linux box, ls -a from bash shows

lrwxrwxrwx 2 jeff jeff   72 Apr  3 14:10 junction-to-other -> /media/jeff/My Book/link-test/sub_other
lrwxrwxrwx 2 jeff jeff   68 Apr  3 14:10 symd-to-other -> ../sub_other
lrwxrwxrwx 2 jeff jeff  116 Apr  3 14:10 sym-to-other -> /media/jeff/My Book/.NTFS-3G/E:/link-test/sub_other

Invoking the DirectoryInfo constructor with "junction-to-other" results in a DirectoryInfo object whose Attributes property contains Directory, but not ReparsePoint. Constructors giving the other two types of symbolic link behave as expected.

   var d = new DirectoryInfo("symd-to-other");     // OK, Attributes has Directory | ReparsePoint
   var s = new DirectoryInfo("sym-to-other");      // OK, Attributes has ReparsePoint
   var j = new DirectoryInfo("junction-to-other"); // Bad, Attributes has Directory, but not ReparsePoint

[JeremyKuhne]

dotnet/corefx#17843 details a scenario where not having this support breaks (deleting the reparse point).

[carlossanlop]

@iSazonov What does PowerShell do when the user is on Unix, inside an NTFS drive, and sees a junction?

[iSazonov]

@carlossanlop Do you ask about symbolic links? I never tested. PowerShell do nothing specific for the scenario. It uses .Net API for file operations and sometimes p/invokes Stat()/LStat()/ReadLink(). So PowerShell behavior is entirely dependent on the underlying API.

I think we should consider WSL and non-WSL Unix scenarios separately because behavior can be highly dependent on Unix NTFS driver. I'm not even sure that Microsoft would want to rely on third-party NTFS driver.
Notice, the Unix NTFS driver must expose the symbolic link flag in Mode field of Stat struct in right way. ReadLink must resolve target correctly too (there could be cross-volume scenarios NTFS <-> Ext4).

[carlossanlop]

behavior can be highly dependent on Unix NTFS driver

Yes, precisely that's why I wanted to ask.

The Unix NTFS driver must expose the symbolic link flag in Mode field of Stat struct in right way

Interesting. I'm going to test it when I get a chance.

Do you know if Unix APIs like readlink/stat/lstat are capable of consuming an NTFS driver if available?

[iSazonov]

Do you know if Unix APIs like readlink/stat/lstat are capable of consuming an NTFS driver if available?

Why not? :-) Ext4 is not the only file system on Unix.

For information https://github.com/tuxera/ntfs-3g/search?q=symbolic&type=wikis