Icons for Hard Links

[tt_1111]

Not a bug, more a request:

In TC v9.0 junctions to folders links very shown with a different icon (quasi transparent / light blue colour).

In TC 9.1 the icons appear as normal folders, to distinguish them from thos you have to look at the description/type column.

A little redundancy doesn't hurt here; it was easier to work with the old behaviour (different icons).

Maybe there is some well hidden switch to change this. However a simple update of an existing version shouldn't bring about such changes.

[Horst.Epp]

Set the option "Show overlay icons"

[ghisler(Author)]

Maybe I should always show link overlay icons even if that option isn't checked?

[petermad]

Maybe I should always show link overlay icons even if that option isn't checked

I think this a good idea for the folder links.

[Horst.Epp]

Maybe I should always show link overlay icons even if that option isn't checked?

Yes, good idea

[MVV]

junctions to folders links

Do you mean just "junctions"? Because "junctions" are already "folder links"... And please correct topic title, "hardlinks" are not "folder links" at all...

Maybe I should always show link overlay icons even if that option isn't checked?

I agree that junctions/symlinks should always have arrow icon regardless of overlays (maybe some additional flag that is enabled by default).

[ghisler(Author)]

OK, I have added this now for junctions/symlinks to folders (but not to files).

[ghisler(Author)]

This should be changed in TC 9.10 beta 3, please test it!

[petermad]

Confirmed changed in TC 9.10b3

[drundanibel]

Hi!

OK, I have added this now for junctions/symlinks to folders (but not to files).

But why not for files? I've been searching for hours for ways to make hard linked files visible as such in Total Commander (8.51a) and can't find any. I created my hard links with "mklink /H" as well as with the TC plugin NtfsLinks. But even the plugins NL_Info and NTLinks, as well as TC itself, call them normal "files" and apparently don't provide any further information. Wouldn't that be possible in any way?

Thanks + regards!

[MVV]

You can only detect symbolic links to files, not hardlinks. Symlinks are special entries that hold path to target. Hardlinks are completely equal file instances that may be in any folder within same volume, and file body exists until you delete all file instances, so there is no sense in highlighting such "files", anyway it is impossible to say which of them is the main one. The only way of detecting files with hard copies is by number of hard links - for "normal" files it is 1, but if you make a hardlink for a file, both the source file and the link will show 2 copies, and these ones will be equal in rights. You can have any number of hardlinks for every file.

E.g. many standard Windows binaries have some hard copies, e.g. C:\Windows\write.exe has 4 copies: C:\Windows\write.exe, C:\Windows\System32\write.exe and two under C:\Windows\winsxs folder. You can see list of hard copies with NTLinks plugin.

Keep in mind though that every hard link has its own copy of primary file attributes (archive/readonly/hidden/system and timestamps) and its copy is synchronized with file body attributes when you open the body via that hardlink, so file hardlinks may show different attributes until you open file via all of them (in Sync tool you have to use compare by contents for updating attributes).

[drundanibel]

Many thanks MVV,

for this very good introduction! Still yesterday afternoon I read myself a little deeper and alredy noticed my misunderstanding of hard links. This and your confirming remarks now have led me to the realization that soft (or symbolic) links are much better suited for my purposes anyway, since only this way I can exchange the actual sourcees for updates centrally without having to adapt all my links to them at the same time.

So far I only failed because of the Windows security concept for symbolic links, according to which not only admin rights are needed to create links, but also their use on remote computers must be allowed before by "fsutil behavior set symlinkevaluation R2R:1". Can anyone explain to me why symbolic links are handled so more strictly by Windows than hard links?

[MVV]

Yes, you need admin rights for creating symlinks. That's why I mostly use junctions instead of symlinks for folders. But there is no old equivalent for file symlink.

I've never used file symlinks for remote access so never noticed this default setting... But I use junctions very often, in shared folders too, and they work perfectly. But with junction you can only open entire folder, not specific file.

There is another issue with file symlinks: unfortunately they don't reflect size and timestamp of target file (symlink size is always zero and timestamp shows when the link was created).

[drundanibel]

Yes, you need admin rights for creating symlinks. That's why I mostly use junctions instead of symlinks for folders.

I've just checked again whether junctions would also be an alternative for my purposes. But with these again symbolic links, which are located within the linked directory, cannot be resolved.

Why do you need remote links to remote files? If you make local link to local file on a remote machine (e.g. in a shared folder), it will be accessible remotely and resolved w/o triggering remote-to-remote requirement.

That does not correspond to my findings: On my remote computer I have set relative symbolic links to files and directories. They work fine directly on the machine, but (without that R2R setting) only partially from my local computer: In Windows Explorer, for example, access works fine. In Total Command and an application that is supposed to work with these files, it doesn't.

There is another issue with file symlinks: unfortunately they don't reflect size and timestamp of target file (symlink size is always zero and timestamp shows when the link was created).

Yeah, that's true, but for me, that's the easiest thing to get over.

[drundanibel]

One more addendum, even if we are gradually moving off-topic: For some of my files (fortunately those that I never have to replace, but only edit continuously) I now have no choice but to rely on hard links, as these have to be committed in a Git repository. Because Git only recognizes symbolic links as what they are (files that contain a path reference) and doesn't replace them internaly with the contents of the linked files.

See for more details here: https://stackoverflow.com/questions/954560/how-does-git-handle-symbolic-links