5

Symlinks created in Linux on NTFS drives (ln -s) appear in Windows as short files with contents IntxLNK + 0x01 + (UTF-16 encoded target path) -- probably Interix. I want to write a script to convert them, when booting in Windows, to proper NTFS symlinks, using WSL's ln. However, I don't know how to detect short files that are really Linux symlinks, except by looking at each file's content, which would suck for a large filesystem, and would fail for plain files starting with the magic.

Why NTFS-3g still cannot create proper reparse points like the Windows mklink or WSL2's ln -s, even though such Windows symlinks work properly under Linux, and even though getfattr -n system.ntfs_reparse_data can read the NTFS symlink data, is beyond me. It should really be just a simple setfattr, though I don't know what to put in the attribute.

So, is there a way to detect symlinks created under Linux using file metadata (not contents)? I'm sure the Linux symlinks have some special attributes, because NTFS-3g can distinguish between plain files containing the InterLnkx magic and actual symlinks containing the same magic.

Related (no answers): https://www.reddit.com/r/linuxquestions/comments/env60r/converting_linux_symlinks_to_windows_symlinks/

Python script to convert; detection by file contents

Improve this question
3
  • I'm assuming that a stat under WSL just shows these as regular files?
    – NotTheDr01ds
    Feb 8, 2021 at 18:06
  • 3
    Creation of reparse point-based symlinks was implemented in ntfs-3g two weeks ago. Though it uses the WSL-specific reparse tag, not the native Windows 7–10 symlinks (possibly because those don't exactly match Linux semantics).
    – u1686_grawity
    Feb 8, 2021 at 20:13
  • 1
    well, the main issue is to have Windows - Linux interoperability at least for symlinks that stay within the drive and link to "real" files/dirs. So that change wouldn't solve it, I guess?
    – usretc
    Feb 9, 2021 at 4:09

1 Answer 1

Reset to default
1

I figured it out using ntfsinfo and comparing two files -- a symlink made from Linux and a copy of the symlink file created in Windows.

It has to be a system file (ATTRIB +S on Windows, or use ntfs_attr.sh at https://gist.github.com/Explorer09/ac4bf6838c271a9968b3 on Linux). As soon as the system attribute is turned on, NTFS-3g sees the file as a symlink, and if it's turned off, it becomes a plain file. So... on to scripting.

Improve this answer
1
  • Ahh, good for you. It still fails on my Win10 even after ATTRIB +S. (FTR: FAR Manager shows LX_SYM as the file type for those links created by the WSL Debian (12).) I'm not sure if the NTFS driver even sets it as a reparse point (which is unfixable by ntfs_attr.sh). Or, actually, wait, it does. So, it's probably that rep. point tag mismatch @u1686_grawity mentioned at the question. Actually, I'm baffled why it worked for you. :-o
    – Sz.
    Aug 23, 2023 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .