Experiment: How Windows deals with Linux symbolic links.

This is not a question, I am just sharing my observations. It seems no one has documented this before. I did these tests both with Windows 7 and 10 and both behave the same in this regard.

I created a symlink on NTFS on Linux:

ln -s example.txt symlink

On Windows, it appears as a system file (a file with the "system" attribute set and the gear icon). Its contents appear like this in Notepad:

湉硴乌ŋexample.txt

"example.txt" is replaced with the name of the source file.

Edit: It can also contain paths:

湉硴乌ŋsubfolder/example.txt

The symbolic link can be renamed and moved and even copied on Windows and still remains a valid symlink on Linux. But if you change the content in Notepad and then save the changes, it will also lose its symlink status.

If you edit its attributes on Windows (properties window or attrib command), it loses its symlink status. Tested again. attrib -s removes symlink status, but adding read-only attribute does not. Also, attrib +s reinstated symlink status.



Hardlinks created on Linux work on Windows just the same: if you change the content of one file, so does the content of the other file. The attributes also synchronize between hardlinks on Windows.

If you want to work with links under both Linux and Windows, it is best to use hardlinks because Windows does not understand Linux symlinks and Linux file managers do not recognize Windows .lnk files. At least not yet.

FAT32 and exFAT do not support Linux symlinks and hardlinks at all. It seems those file systems are intended to be as simple as possible to make it easier to implement them on pretty much all devices, including simpler devices like compact cameras and HiFi with USB ports and car radios, so they lack advanced features like symlinks, hardlinks, compression, journaling, POSIX file names, sparse files, resident files (content of very short files stored inside INDX entry).

(I hereby release this post into the public domain under CC0 1.0.)

you can find a lot of info about it, like: https://superuser.com/questions/1837...referring-to-a
or: https://unix.stackexchange.com/quest...symbolic-links

Originally Posted by exerceo I created a symlink on NTFS on Linux

You're brave.

Which NTFS filesystem driver do you use in Linux? I don't trust NTFS enough to use it anywhere outside of Windows.

Originally Posted by rkelsen You're brave. Which NTFS filesystem driver do you use in Linux?

It is mounted as "fuseblk", which is NTFS-3G as far as I remember. I tested it with ntfs3 and symlinks created under fuseblk (ntfs-3g) do not appear as symlinks on ntfs3, but new symlinks can be created. Also, ntfs3 shows file birth times unlike fuseblk.

Here is a hexdump of the symbolic link. It is a symbolic link to a file called "hardlink", not a hardlink itself. It looks like the file path is UTF-16 encoded (two bytes per character), and there is "IntxLNK" at the beginning.

00000000  49 6e 74 78 4c 4e 4b 01  68 00 61 00 72 00 64 00  |IntxLNK.h.a.r.d.|
00000010  6c 00 69 00 6e 00 6b 00                           |l.i.n.k.|
00000018

Originally Posted by rkelsen I don't trust NTFS enough to use it anywhere outside of Windows.

Why not? Because it is proprietary? Or is it bad for other reasons?

NTFS was useful for file transfer between {Linux} and {Windows 7 or Vista} because they can only mount unclean exFAT volumes as read-only, so chkdsk had to be run, and FAT32 has limited usefulness for an obvious reason. Windows 10 thankfully allows writing to unclean exFAT volumes. I don't know about Windows 8/8.1.

Originally Posted by exerceo Why not? Because it is proprietary?

Yes. Most support for NTFS outside of Windows has had to be reverse engineered.

No operating system written outside Microsoft can ever implement NTFS 100% correctly because there are parts of it which Microsoft keeps secret.

The Paragon driver in the kernel goes further than any other Linux NTFS driver ever has, but there remains an element of risk whenever you use NTFS outside of a Windows environment. We can debate the degree of risk, but nothing will change the fact that the risk exists while NTFS remains proprietary.

This risk doesn't exist at all under Linux with, for example, ext4.

Originally Posted by exerceo NTFS was useful for file transfer between {Linux} and {Windows 7 or Vista} because they can only mount unclean exFAT volumes as read-only, so chkdsk had to be run, and FAT32 has limited usefulness for an obvious reason. Windows 10 thankfully allows writing to unclean exFAT volumes. I don't know about Windows 8/8.1.

I don't think linux allows writing on any "dirty" volumes. Also Windows restricts it, that is just a "trick". And in general it is not a good idea (to write to an unclean device).
Anyway, NTFS was useful because there were no better/other possibilities, otherwise in the linux world you need to avoid ntfs (if possible).

We have now "native" ntfs support on linux, thanks to the mentioned paragon driver (called ntfs3), which is much better that the old ntfs-3g, but still not an "official", microsoft certified software.

That ntfs3 driver is mostly good, writes fast, 99% of the time there was no problem at all.

There was one time it broke hard, can't remember the exact details or output but I know how it started.
When I went to unpack a large zip file from ext4 to ntfs and it didn't complete properly for some reason, I've tried to delete the output files and couldn't.
So I unpacked from ext4 to ext4 and did an overwrite of those ntfs files, but then it was so messed up the chkdsk verification took few hours because $MFT seemed corrupt.
After those few hours of $MFT verification it was fine, I think only windows chkdsk can fix it if/when it happens.

My advice in all such cases is: "Go to Windows," and set up the filesystem the way you want it. Then, access the Windows material as a remote volume hosted by Windows. They have very solid networking support.

Originally Posted by rkelsen We can debate the degree of risk, but nothing will change the fact that the risk exists while NTFS remains proprietary.

I can confirm that. I have an NTFS drive with some folders with POSIX-only characters (":" and "|") that were created by saving pages on an older Firefox version on Linux which did not filter those characters. Now those folders are inaccessible. When trying to list their contents on Linux, I get an input/output error. This only happened on some folders, not all. Some others with those characters are prefectly readable. I have not managed to recreate this bug.

There are no folders without those characters that are unreadable, so it must somehow be related to those characters.

While Windows does not support characters like the colon ":" and pipe "|", NTFS has a POSIX subsystem (even Microsoft says so) and therefore does normally support such characters.

Probably running chkdsk from Windows would make the contents accessible again inside found.000, but before that I'll have to back up anything else because I don't trust chkdsk not to cause some unwanted side effects.

So while NTFS can indeed "blend into" a Unix environment, it is pushing its limits.