Do not follow NTFS links

[zupermario]

Hello people,
it's possible to configure TC to DONT follow any symbolic, hard, junction or any other (damned) ntfs link on search, copy, move and any other operation?
This often cause infinite loop searching and copying. And, if i doubleclick on a link (for example: "Documents and settings") on an external drive (for example "J:"), TC show me "J:\Documents and settings", but really i'm working on "C:\Documents and settings" !!
I have repeatedly threatened to wipe useful data assuming i was working on a path in external drive, but instead, cause the link, I was actually working on my data on c:

Thanks.

[Flint]

zupermario
There is no such function in TC, unfortunately. All you can do is find all links yourself, put them into TC ignore list and then do what you need. This way TC will simply ignore them.

But you cannot blame TC for it showing a link target contents when you open the link: that's exactly how links are supposed to work, it's a universal concept used widely in various operating systems for different purposes. So, you just need to be aware of such peculiarities of links and make allowance for this behaviour. You can also configure TC to highlight the symlinks so that you easily see that you are opening not a usual folder but some external location (and even display the real target of this location e.g. in a tooltip).

And what about infinite loops — there should not be any, Ghisler worked much on eliminating them. There's still a possibility that a loop will occur if some link has specific permissions (such as allowing you to go inside but disallowing you to read its target path), but normally such situations should not happen. If you found a use-case when TC goes into an infinite loop, please, report this bug in the Bug reports forum (after checking whether the problem still exists in the latest beta-version of TC, of course).

[HerbieH]

Hello Flint.

I must say, that I totally disagree with your point of view. I think, that a tool like Total Commander absolutely should have a switch to activate the treat of junctions, symbolic etc. the way, zupermario (and I) want to: that is, to ignore the content of the link, and just copy it, as if it was a 'standard' windows shortcut.

As it is now, I have to use another program 'fastCopy' from SHIROUZU Hiroaki, if I wish to copy a junction/symbolic link itself, and NOT the content of the link.

Unfortunately, I havn't found a program, that can make a 'search', ignoring the contents of a j/s, but I really wish, TC itself could do both.

PS: The 'infinite loops' discribed by zupermario, has nothing to do with mr. Ghislers effords eleminate them. They WILL appear, if you have 'nested' j/s and do a search. A switch to treat j/s as described above, would of course avoid this problem.

Greetings from

[Flint]

I must say, that I totally disagree with your point of view. I think, that a tool like Total Commander absolutely should have a switch to activate the treat of junctions, symbolic etc. the way, zupermario (and I) want to: that is, to ignore the content of the link, and just copy it, as if it was a 'standard' windows shortcut.

Then you must have missed the point. I'm completely and totally for such an option, otherwise I would not use the word "unfortunately" in the very first sentence.

But you must understand that automatic copying a bunch of data, among which somewhere deep inside there might appear symlinks, or searching through them, or any other function that processes lots of data automatically, is one thing, and just navigating manually through files and folders in file panels is completely different thing. To have an option to skip links or treat them specifically in the first case is a must — no doubts of that. In the second case however links must be links, they must behave as they are intended to behave, that is, show contents of the target dir while making impression that you are in a different dir. You don't like it? Then just don't use links, they are not what you want.

While manual navigation TC does what it must do according to the originally designed functionality. To help you not get lost (when working e.g. with OS-created links), TC allows you to easily distinguish links by their icons, by the name in the "Size" column, you can mark them by color or show additional info in custom columns (via plugins), etc. So you know that you are going to enter not an ordinary dir but a link — so just don't enter it if you don't want to.

PS: The 'infinite loops' discribed by zupermario, has nothing to do with mr. Ghislers effords eleminate them. They WILL appear, if you have 'nested' j/s and do a search. A switch to treat j/s as described above, would of course avoid this problem.

That's wrong. As I said above, Ghisler worked hard exactly to detect infinite loops caused by links while searching and prevent TC from entering them.

[ZoSTeR]

You could try and define a file/search pattern with ntlinks.

Either (from wincmd.ini [searches])

Code: Select all

No Links_plugin=ntlinks.Obj_Type != Junction & ntlinks.Obj_Type != Symlink & ntlinks.Obj_Type != SymlinkD

or

Code: Select all

No Links2_plugin=ntlinks.Obj_Type = File | ntlinks.Obj_Type = Dir

Not sure about the other Obj_Type values so the first one should be safer.

[MVV]

ZoSTeR, unfortunately this won't prevent TC from entering junctions during search.

[zupermario]

But you must understand that automatic copying a bunch of data, among which somewhere deep inside there might appear symlinks, or searching through them, or any other function that processes lots of data automatically, is one thing, and just navigating manually through files and folders in file panels is completely different thing. To have an option to skip links or treat them specifically in the first case is a must — no doubts of that. In the second case however links must be links, they must behave as they are intended to behave, that is, show contents of the target dir while making impression that you are in a different dir. You don't like it? Then just don't use links, they are not what you want.

While manual navigation TC does what it must do according to the originally designed functionality. To help you not get lost (when working e.g. with OS-created links), TC allows you to easily distinguish links by their icons, by the name in the "Size" column, you can mark them by color or show additional info in custom columns (via plugins), etc. So you know that you are going to enter not an ordinary dir but a link — so just don't enter it if you don't want to.

I am very concerned about how my experience with TC will evolve with the increasing spread of W7 and its link.
TC is a massive files/folders handler: a lot of work with few clicks, and completely predictable and accurate results.
Until now.
Now, instead, I must be careful of the links. I have to manually check every subdirectory of the directory i want to manipulate, because any sort of link hidden in some kind of sub-sub-sub-directory can deflect the cutting of my knife (TC) with tragic results.
This way of working is no longer "the TC way" (the smart one way) and I hope that, despite my poor English in describing the problem, will be taken into serious consideration the possibility of a switch in TC to DONT follow the links when copying, deleting and searching.

That's wrong. As I said above, Ghisler worked hard exactly to detect infinite loops caused by links while searching and prevent TC from entering them.

I cant evaluate the efforts that Ghisler has done to detect infinite loops, but I can assure you that unfortunately have been unsuccessful: just change the attributes of ownership of any hard disk with W7 installed (=become owner of the entire contents of the hard disk, so you have the permission to access every folder), and then start a search on this hard disk, to realize that TC goes inexorably in infinite loop.

[Flint]

Now, instead, I must be careful of the links. I have to manually check every subdirectory of the directory i want to manipulate, because any sort of link hidden in some kind of sub-sub-sub-directory can deflect the cutting of my knife (TC) with tragic results.
This way of working is no longer "the TC way" (the smart one way) and I hope that, despite my poor English in describing the problem, will be taken into serious consideration the possibility of a switch in TC to DONT follow the links when copying, deleting and searching.

Again, I'm totally for this suggestion. When copying, deleting, and performing any other automatic operation which goes deep into file system, TC should provide an option to deal with links in a way user chooses.

I cant evaluate the efforts that Ghisler has done to detect infinite loops, but I can assure you that unfortunately have been unsuccessful: just change the attributes of ownership of any hard disk with W7 installed (=become owner of the entire contents of the hard disk, so you have the permission to access every folder), and then start a search on this hard disk, to realize that TC goes inexorably in infinite loop.

You should have posted this in the Bug Reports section, where the problem was discussed. Yes, in this specific scenario I confirm that infinite cycle starts, therefore Christian should be informed so that he could see what's going wrong in this particular case and fix it.

[Balderstrom]

@zupermario

TC's Junction handling has been a problem for 11+ years (Since Windows 2000), it's not just suddenly a problem. It's just affecting more users now, as Win2K/XP didn't make use of SymLinks/Junctions for the most part, and didn't make it easy for users to create them.

In some ways TC's handling of Junctions has been better than Windows native Explorer, and in others it has been worse.

Try cloning a User folder with TC and see the mess that gets created due to TC automatically converting SymLink/Junctions to Normal Folders.

One needs to use something like Hardlink Shell Extension to confidently clone directory structures in Windows and have control over what is actually happening.

As far as I know, at least, there is no longer any Data loss from using TC for Copying/Moving junctions, just a complete lack of control over how the data on the harddrive gets duplicated ad-nauseum to no point whatsoever.

If I have a Junction on C:\ pointing to a data location on a different drive, say D:\. And I copy the folder from C to D...

Or attempt to use a junction to redirect program data on a USB-Drive to a harddisk, then copy the contents of said USB.

Among many other scenarios where data will get moved or duplicated and will have to be painstakingly cleaned later.

[EndreB]

I am very concerned about how my experience with TC will evolve with the increasing spread of W7 and its link.

I have the same concern and I believe more options to deal with links (copy link or content, skip on search, create links) it would really benefit TC.

[Dalai]

I am very concerned about how my experience with TC will evolve with the increasing spread of W7 and its link.

I have the same concern and I believe more options to deal with links (copy link or content, skip on search, create links) it would really benefit TC.

You can skip links on copy if you set the CopyLinks option (see TC help, section 4.b). However, I admit, although I heavily use Junctions, I don't use CopyLinks myself. Why? Because it's not a good implementation, even less for a portable TC. Sometimes I want to be able to copy the link, sometimes I want to copy the link's target. As it is now, you have to switch the setting, restart TC and copy the files and then reset the option (if you don't forget it). The suggestion to Ghisler to add the option to the copy dialog was denied because it would add more complexity to an already overcrowded dialog... Well, now we have a copy dialog without this option and I'm wondering who's using the CopyLinks option (and how).

The creation of Junctions and Hard Links can be done with NTFS Links.

EDIT: Sorry, the first part of my post is wrong . You don't skip the links with the CopyLinks option, but the files/directories they're pointing to, so the links will be (re)created by TC in the destination directory of the copy process.

Regards
Dalai

[EndreB]

Many thanks for the quick pointer to CopyLinks, Dalai! It does help, even if extending the Copy/Move options would be better.

Endre