Feature-request: Link-Aware operation (Junctions, Directory Symlinks, File Symlinks, Hardlinks)

[LogicDaemon]

Hello.

As 9x became completely irrelevant more than a decade ago, and XP/2003 about 5 years ago, and symlinks are "First-class" citizens of modern Windowses, I think TC should completely respect them in following aspects:

* When copying:
1. [Configuration] CopyLinks= should contain one more mode: Copy links and, if the link points inside the copied tree, change the target path to the same path in destination directory relative to copied source. For example:
after copying C:\dir1 {where symlink C:\dir1\sl points → to C:\dir1\subdir\sltarget,}
to C:\dir2, C:\dir2 should contain symlink C:\dir2\sl pointing to C:\dir2\subdir\sltarget
2. Copy dialog should contain dropdown with options what [Configuration] CopyLinks= offers, including the option above
3. Copy dialog should have option to make hardlink-copy
4. Copy dialog should have option to make symlinks of selected items instead of copying the tree
5. Copy dialog should have option to make Junctions of selected directories (instead of everything above: for example, if 3 and 5 are checked, files are hardlinked and directories became Junctions in destination; if 4 and 5 are checked, files are symlinked, and directories became Junctions in destination)

My UI preference is separate 3,4,5 in 2 dropdowns: File: [copy/hardlink/symlink], Directory: [recursive copy/Junction/symlink], and
two more dropdowns for 1,2:
- Links pointing outside the copied tree: [copy what they point to|copy as is|update link drive|ignore (skip)]
- Links pointing inside the copied tree: [copy what they point to|copy as is|update link relative to copied tree|update link drive|ignore (skip)]

"update link relative to copied tree" is what I described in "1" above, and "update link drive" is what CopyLinks=2 does now.

* When calculating directory size:
1. Hardlinks should be calculated once
2. Junctions, file and directory symlinks should be ignored (even explorer.exe understands that; but when calculating %APPDATA%\.. size, TC tries to follow symlink-loops until hits path length limit)
* Maybe add option to calculate "full" size, which will include all hardlink-copies, but this is only needed when copying/moving to filesystems not supporting links.
** Calculating directory size with all external symlinks/junctions but ignoring all internal ones may also be useful, for example, to estimate a project size with all dependencies. But then it should probably also include windows shell ".lnk" links, which is totally out of scope of this post.

* When moving/renaming – as with copying, but by default:
1. Hardlinks inside moved subtree should be preserved, even when moving to over volume
2. Junctions and Symlinks which point inside moved subtree, should be updated to point to same place in subtree relative to moved location (maybe with checkbox toggle in move dialog to avoid that when needed).

* "Editing" symlinks – that is, what it points to.

When destination does not support links [FAT32?], TC should:

1. in copy/move dialog, warn user (like exclamation in Find Files dialogue when "[x] Search archives (all except for UC2)" is checked)
2. default to copy file links as files, but ignore directory links (to avoid recursion)

[MVV]

Currently TC already tries to patch copied links, but sometimes does it wrongly. And the most sad thing is that it can't be configured per operation, only globally in INI.
Creating all kind of links now can be done with e.g. my NTLinks Maker, editing may be done with NTLinks plugin (though you have to start elevated TC for editing symlinks).

It is really not easy question how to calculate size of folder. TC calculates full size by default, this size will be required on target if you copy entire folder. Calculating each hardlink only once is a bit specific operation, I think, so may be done with external tools when needed (there is no problem with integration, just button or user-command that gets selection).

[LogicDaemon]

> Creating all kind of links

I'm using usercmd.ini and my scripts with mklink for that.

> editing may be done with NTLinks plugin

I'm using LinkShellExtensions, and not just with TC.

> though you have to start elevated TC for editing symlinks

either that, or use Windows Developer Mode (https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/#T6Te6jQqAwsY1sED.97)

> It is really not easy question how to calculate size of folder. TC calculates full size by default, this size will be required on target if you copy entire folder.

well, only if you copy "old way" handling links as target. But that's exactly my point. By default, TC behaves like it's still in 90s and there's no symlnks in Windows. Though even xcopy has /B flag (Copies the Symbolic Link itself versus the target of the link).
Again – even windows's explorer.exe Properties window shows sizes more right (though it does sum hardlink sizes like it's separate files).

> Calculating each hardlink only once is a bit specific operation, I think, so may be done with external tools when needed (there is no problem with integration, just button or user-command that gets selection).

well, everything TC does can be done with "external" tools, question is convenience and accessibility. Currently, I'm using DirSizeCalc plugin, but then TC does not sum sizes of selected folders…

I don't even see what's the problem is here. Just keep [set] of inodes (or what's NTFS equivalent of that? https://stackoverflow.com/a/7163783) of files while calculating size, and if same inode appears again, ignore it.