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.
NTLinks + NTLinksMaker: NTFS links creation and information
Moderators: Hacker, petermad, Stefan2, white
-
Balderstrom
- Power Member
- Posts: 2148
- Joined: 2005-10-11, 10:10 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).
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).
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.
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.
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'
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'
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").
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
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
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. 
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
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
File NTLinks.wdx from package wdx_NTLinks_1.5.1.156.zip (via http://www.totalcmd.net/download.php?id=ntlinks ):MVV wrote:New version released. :)
NTLinks 1.5.1.156
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
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.
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.
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?
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?
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).
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).
-
orcommander
- New Member
- Posts: 1
- Joined: 2011-12-13, 09:06 UTC