NTLinks + NTLinksMaker: NTFS links creation and information

Discuss and announce Total Commander plugins, addons and other useful tools here, both their usage and their development.

Moderators: sheep, Hacker, Stefan2, white

Post Reply
User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom » 2010-10-08, 09:23 UTC

I didn't even realize they were bad, as the hover kept saying "valid".

I recently did a small tutorial for locating Folders that don't contain a cover.jpg, and while testing it those ones were among 5 other folders of mine that didn't have a cover -- then realized I couldn't enter them and they were bad.
*BLINK* TC9 Added WM_COPYDATA and WM_USER queries for scripting.

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2010-10-08, 13:50 UTC

What if their targets were changed to another folders instead of themselves? In such case even loop checking can't help to detect that they are changed.

Anyway the only interesting thing regarding NTLinks is why actual path is not the same as target for link to itself... And I have no idea how to get such link. I tried to create link to itself using NTFS Links addon, actual path and target were same (I've used same paths as in your case).

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2011-06-11, 13:04 UTC

Hi to all, new version is out. :)

NTLinks 1.5.0.124:
+ keeps last file data in cache (should work faster when many plugin columns used)
+ natural mode for symlinks now returns full path even if link contains relative one
+ set/remove target path feature (via Attributes dialog) for mount points/junctions and symbolic links
+ compare files by file/volume index function (for Synchronize by contents dialog)
* max number of expands in real path reduced to 32 (Windows doesn't allow more than 31 reparse points in a path)
* faster algorithm for real path
* fixed some reparse point types
* Unicode and ANSI fields joined together (same fields return ANSI strings in old TC versions)

NTLinks 1.5.0.132:
+ special identical equality icon for index compare (for Synchronize by contents dialog)
* clear cache on refresh or change dir in TC

Now plugin allows to convert folder into junction and vice versa. To edit symbolic link target you need to have admin rights (elevation).

NTLinks 1.5.0.132 displays special identical equality icon (≡) for files with same indexes in Synchronize dialog.

hs2
Junior Member
Junior Member
Posts: 10
Joined: 2005-04-21, 09:38 UTC

Post by *hs2 » 2011-06-13, 07:50 UTC

Thanks for this nice plugin !
The latest version shows a minor problem.
Seems that 'ntlinks.Target path' of a (win7) symlink e.g. pointing to a folder on another drive doesn't work correctly.
Example: 'D:\Foo\Bar\<Symlinked Folder:Else>'
with Symlinked Folder 'Else' = 'E:\Some\Thing\Else'
results in: ntlinks.Target path: 'D:\??\E:\Some\Thing\Else' with 'Valid=No'

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2011-06-13, 13:57 UTC

Hm-m, thanks, I'll check it. By idea, current drive's root should be inserted only for relative paths that begin with \. In case of full path drive's root shouldn't be inserted. And problem has place for every full path, not only for path pointing to another drive (e.g. try to reproduce it with symlink "C:\Users\All Users" - I see path "C:\??\C:\ProgramData").

hs2
Junior Member
Junior Member
Posts: 10
Joined: 2005-04-21, 09:38 UTC

Post by *hs2 » 2011-06-13, 14:08 UTC

Ok - I see. I've recognized the problem with a symlink similar to the given example and I didn't verify other symlinks.
I thought it's related to the other drive b/c I didn't assume that abs. path symlink support itself is broken ;)
Thanks for taking care !

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2011-06-13, 14:42 UTC

I think bug appeared when I've added support for network symlinks (they have special prefix so normal one got broken).

Anyway, I've fixed bug, you may try updated version. Thanks again. :)


NTLinks 1.5.0.140:
+ remove \??\ prefix for symbolic target of mount points too
* wrong prefix for target of absolute symlink

hs2
Junior Member
Junior Member
Posts: 10
Joined: 2005-04-21, 09:38 UTC

Post by *hs2 » 2011-06-14, 07:51 UTC

Works great ! Thanks for the quick fix and keep up the good work.

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2011-06-14, 10:58 UTC

Today I've noticed that Windows understands symlinks and junctions that begin with volume GUID. I can enter such folder normally. It is funny that Windows 7 folder properties shows no details for such links. :lol:

New version released. :)

NTLinks 1.5.1.156 (changes since 1.5.0.140):
+ allows to set path starting with volume guid w/o prefix \??\ (for mount points and junctions)
+ understands symlinks and junctions starting with volume guid
+ gets privilege required to modify symlinks
* shows number of hardlinks for dirs and symlinks

JOUBE
Power Member
Power Member
Posts: 622
Joined: 2004-07-08, 08:58 UTC

Post by *JOUBE » 2011-06-17, 18:36 UTC

MVV wrote:New version released. :)

NTLinks 1.5.1.156
File NTLinks.wdx from package wdx_NTLinks_1.5.1.156.zip (via http://www.totalcmd.net/download.php?id=ntlinks ):

http://www.virustotal.com/file-scan/report.html?id=1b16ba309eb25eabfb263e5988b92cc05866a179c988e985534f5126f99fd852-1308323275 says:
Antivirus - Version - Last Update - Result
AhnLab-V3 - 2011.06.17.00 - 2011.06.16 - Malware/Win32.Generic
AntiVir - 7.11.10.6 - 2011.06.17 - TR/Kazy.14729.1
BitDefender - 7.2 - 2011.06.17 - Gen:Variant.Kazy.14729
F-Secure - 9.0.16440.0 - 2011.06.17 - Gen:Variant.Kazy.14729
GData - 22 - 2011.06.17 - Gen:Variant.Kazy.14729
Ikarus - T3.1.1.104.0 - 2011.06.17 - Gen.Variant.Kazy
nProtect - 2011-06-17.01 - 2011.06.17 - Gen:Variant.Kazy.14729
Symantec - 20111.1.0.186 - 2011.06.17 - Trojan.Gen.2

?

Please Check

JOUBE

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2011-06-19, 08:45 UTC

I can't pass every release to dumb bunch of anti-virus software that have great number of false positives, especially because of dumb "heuristics algorithms".

Recently I had written to NOD developers about wrong positive, and sent them a copy of my TCFS2 tool. Their anti-virus marked file as suspicious just because it called function ClipCursor which is not harmful at all (yes, it may bring some annoying moments if used wrongly, but my tool set clipping for split second). As it was expected, developers answer that they don't want to change anything.

And I can't even know what exactly piece of my compiled code theese anti-viruses treat suspicious so I can't do anything with it. My last build also has some positives.

Thank you for information, I'll know that another my file has false positives.

BTW, now I tried to patch places where plugin calls functions OpenProcessToken, LookupPrivilegeValueW and AdjustTokenPrivileges (if you have interest and hex editor, write 909090909090 at offsets 16BC, 16DE and 16F4 to remove function calls - don't try to use patched file then!), and such patched file got only 4 positives instead of 13 which unpatched file got today. So it seems that dumb heuristic algorithms fear programs that enable privileges (BTW, it is impossible to enable privileges that current user account doesn't have so I don't understand such fear). But it is necessary to enable SE_CREATE_SYMBOLIC_LINK_NAME privilege to edit symbolic links - and it will work only for administrator accounts since user accounts doesn't have such privilege - there is nothing to enable for them. We may only guess what is wrong in patched file for 4 left anti-viruses.

billiebub
Member
Member
Posts: 181
Joined: 2011-04-12, 19:49 UTC

Post by *billiebub » 2011-11-01, 20:42 UTC

Thanks MVV for the great plugin. I use NTFSLinks to create the links and when I use your plugin to see the obj_RealPath, it seems to always show where the link is currently at so for example:

Actual: c:\text1.txt
Link: c:\mylinks\text1.txt

when using the plugin, objRealPath always shows it as c:\mylinks\text1.txt but shouldn't show the actual path of c:\text1.txt?

User avatar
MVV
Power Member
Power Member
Posts: 8403
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2011-11-02, 06:20 UTC

Hm, which kind of link you're talking about?

NTFSLinks (currently) allows to create only one kind of links for files - hard links. Theese links don't support real paths, all hard links of a particular file point to same physical contents and have equal rights, there is no master object (actually every hard link is a master object, if you delete any of them, other one is still keeps file), so real path for any hard link is always path to it.

Target and real path may be resolved only for objects that are really links (symbolic links, junctions etc).

billiebub
Member
Member
Posts: 181
Joined: 2011-04-12, 19:49 UTC

Post by *billiebub » 2011-11-02, 11:55 UTC

Thanks for the explanation. At least now I know what's going on.

orcommander
New Member
New Member
Posts: 1
Joined: 2011-12-13, 09:06 UTC

Post by *orcommander » 2011-12-13, 09:39 UTC

MVV wrote:I can't pass every release....
In version 1.5.2.162 Avast and other antiviruses "have no questions" to plugin. Are you modified code...? Do you remove
+ gets privilege required to modify symlinks
or somehow rewrite that place?

Post Reply