Unpredictable symbolic (symbolic) links in Windows.

The reason for writing was this article Links in Windows, symbolic and not only . It can also be read to familiarize yourself with what hard and symbolic links are in ntfs.
I will continue and share some facts about the obvious behavior of these links.

Immediately make a comment. If there is no ambiguity with Hard Links, there is no confusion with soft or symbolic links. So I will continue to talk about those symbolic links that are made by the program Junction (as well as Alax.Info NTFS Links, Link Shell Extension, etc.)
The experimental programs were: Total Commander, Far, Frigate3, Servant Salamander, WinDirStat and Explorer in Windows XP.

Recursion

I first encountered reference problems a few years ago when I tried to write a “super-duper” utility for finding and removing duplicates. It turned out that the OS's presented search and directory traversal mechanisms fall into recursion when processing directories in which there is a symbolic link to itself or the parent directory. Of course, this can be avoided if you recognize the links and process them in a special way, separately from the directories. But the thesis project interrupted the development of the utility, and then I decided not to waste time on creating the next “duplicate cleaner”. Now I think that in vain.
The fact is that most programs that work with files do not know about symbolic links. And this is where it leads.
')

Search.

Create a directory
X: \ 000
In it we will create a file text.txt and a symbolic link 111 to the same directory X: \ 000
This is what our experimental file managers will give out when searching for a file except Far
X: \ 000 \ text.txt
X: \ 000 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt
X: \ 000 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ 111 \ text.txt

I am glad that the recursion was interrupted so early. But still this behavior is wrong and can lead to errors. Here we found the same file 16 times. Many duplicate search programs will offer to delete this file as a duplicate. Although in fact the file is quite unique.
But Far, it turns out, when searching does not follow symbolic links at all.

Catalog size

This behavior leads to interesting effects when determining the size of the directory. You can make it so that this size will be many times larger than the size of the disk. For example, on my laptop there is a 300 TB folder. The same size trick can be done using hard links.

Among the experimental programs, only WinDirStat and Explorer have correctly determined the size.
With the explorer, everything is clear - he and the implementation of symbolic links in the windows of the brainchild of the same company and it would be strange if they incorrectly used their own link mechanism. But WinDirStat is so familiar with links, probably because it comes from Linux.

Copying symbolic links

When copying links, experimental file managers behaved differently.
* Far - copied symbolic links as links. Those. made a copy of the link and not its contents.
* Explorer for each link asked a question - copy it as a directory or as a link. But I suspect that such a smart behavior was given to him by the installed utility Alax.Info NTFS Links. I could not check how Explorer behaves on windows xp without any extensions, but on windows 2000 explorer leads when copying itself as far.
* All other guides copied the links as directories.
When copying links you need to understand what it is. If the links are copied as files, for example, I will not be able to copy my “INTERNET” daddy in the near future. If you copy links as links, it may turn out that a friend’s directory with movies copied to another hdd in the spotlight will not open, since there were symbolic links inside. And then where did they refer to another hdd. In general, when copying, Explorer behaves most correctly in the installed correct extension.

Then I decided to check if the archivers support symbolic links. It turned out that no. All archivers from my collection (including 7Z, winrar) do not save symbolic links. Unfortunately in my collection there were no ported archivers like tar. I hope that programs from Linux will help again.

As for hard links to a file, all programs copy, archive them as files, not recognizing the link or not. In principle, this is expected.

Remove symbolic links.

When deleting symbolic links, Frigate3 and Servant Salamander excelled. They not only deleted the link, but also carefully cleared the contents of the directory to which it referred. The rest of the experimental deleted only the link.

Paranoid.

Removing hard links is not a problem. True, I don’t understand why I can’t remove one hard link to a file if it is opened via another hard link.
It must be remembered that hard links are essentially different names for the same file.
When using programs that permanently overwrite a file (for example, Sdelete ), permanently deleting one hard link will result in the other hard links to the file refer to a bunch of garbage. In this case, this behavior is logical and correct. If we already overwrite files, then for good.

Findings.

Probably because symbolic links were not popular in Windows, many programmers forget about them. Or maybe links are not popular because programmers forget about them and their programs work with links as they will. In general, be careful when using symbolic and hard links and check how your file manager handles them.

Shl. It turns out there is not enough karma to write to a thematic blog. Anyway. Maybe here someone will be useful.

UPD: Experiments were performed in Microsoft Windows XP Home Edition 32bit SP3
Total Commander 7.04a
Far 1.70
Servant Salamander 2.0
WinDirStat 1.1.2.80 (Unicode)
Frigate 3.21.2.71
Explorer 6.00.2900.5512

I took note of Busla and changed the translation of the Symbolic link to a more common version.

UPD2:
In order to clarify once again what it is about and remove differences in terminology sown with a light hand of MS.
Having looked through msdn, I understood that in the end MS came to a common opinion. Sort of. And in Windows Vista, they made some symbolic link that are created by the CreateSymbolicLink function.
And those symbolic == symbolic == soft links that were (and are) in earlier versions of Windows (2000, XP) are some kind of reparse point. And they are created like this:
memset (reparseInfo, 0, sizeof (* reparseInfo));
reparseInfo-> ReparseTag = IO_REPARSE_TAG_MOUNT_POINT;
reparseInfo-> ReparseTargetLength =
_tcslen (targetNativeFileName) * sizeof (WCHAR);
reparseInfo-> ReparseTargetMaximumLength =
reparseInfo-> ReparseTargetLength + sizeof (WCHAR);
_tcscpy (reparseInfo-> ReparseTarget, targetNativeFileName);
reparseInfo-> ReparseDataLength = reparseInfo-> ReparseTargetLength + 12;

DeviceIoControl (
hFile,
FSCTL_SET_REPARSE_POINT,
reparseInfo,
reparseInfo-> ReparseDataLength + REPARSE_MOUNTPOINT_HEADER_SIZE,
Null
0,
& returnedLength,
NULL);

So, since I do not have a whist, it is a question of reparse point. Although I assume that symbolic link will also surprise the ambiguous behavior in different programs. For the problem is mostly not in the links, but in the fact that some programmers forget about them.