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
MVV
Power Member
Power Member
Posts: 8397
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2009-08-28, 22:09 UTC

Postkutscher wrote:Strictly speaking I would like to know about symlinks, they are the one not mentioned in NL_info docs ;)

The second thing...the validity of reparse points is dependent on permissions of TC`s user. All RPs where I have no access are marked as not valid.
I heard about symlinks in NL_Info topic. I opened my Users folder and saw that I really have RP's of different types. Although NL_Info doesn't support symlinks, the main goal for NTLinks was NTFS indexes.

Junctions may point only to folders, and only within NTFS file system. During creation of junction, this folder must be available.

Symlinks may point to any path, you need admin rights in order to create symlinks. First of all, symlinks are made for files because there was no possibility to make low-level link for file at another partition before. But symlinks also available for directories - special symlinkd type of RP. Symlink may be created for any kind of target - even if doesn't exist (but you can't browse file symlink or view dir symlinkd even if it looks just as file) - and apps will threat this object as if it was real file or folder! System command for creating symlinks and junctions comes with Vista/7 - mklink.

Yes, if you limit permissions to RP or to target file/folder, you wouldn't have chance to enter it or to get info.

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

Post by *Balderstrom » 2009-08-29, 02:25 UTC

Good stuff, love the Tiny File sizes :-)
My russian is not so good, but the site apparently is designed well I just guess at what I need to type and click hehehe.

NOTE:
I was thinking about recursive display of referenced junctions, but I haven't quite nailed down how it might work - or if its just completely pointless!

For example, Hovering over directory "¤TC":
C:\Usr\ME\Application Data\¤TC --> C:\Usr\Allxx\AppData\¤TotalCMD
Where:
C:\Usr\ME --> C:\mntHD\HDa3\Win2K_Usr\_C_\ME
C:\Usr\Allxx --> C:\mntHD\HDa3\Allxx_Usr
C:\mntHD\HDa3 --> \\?\Volume{__UniqueDriveAlphaNumericString__}
...Yeah I know, but that all makes sense to me. And keeps stuff safe and organized (Separation of Data and OS) for a near-future multiboot system.

The other thing, though it's not exactly a NTLinks request:
Anyone know how to get access to a ToolTip? I.E. copy the ToolTip to Clipboard or CommandLine or the like. I know how to resolve a folder name with a batch script as such, but I have been unsuccessful in getting TC to perform an action for an InternalAssociation for Folders.
I could always also just use the button on my buttonBar:
Command:cmd.exe /c "junction -s && set /p input=?"
But that wants to try and find every junction in every folder of the current path.


[OT]
@MVV, I'm curious what did you use to pack a multi-file cab? The research I did on that talked about writing a .inf-like file describing the files to be contained within the .cab.
[/OT]

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

Post by *MVV » 2009-08-29, 08:05 UTC

Balderstrom wrote:Good stuff, love the Tiny File sizes :-)
Me too=)
But this is possible only if I don't need CRT (i.e. new/delete operations). If CRT is used, file will contain its code - so some tens of KBs of aaidional stuff (or will require some dinamic library linked like MSVCR71.dll or MSVCR80.dll w/o which your program won't launch at all).
Balderstrom wrote:My russian is not so good, but the site apparently is designed well I just guess at what I need to type and click hehehe.
I'm sorry, this is the only share site where I was registered (since WebFile.ru), but today this is not only file exchanger (BTW I use only file exchanger). I even not immediately understood that it has no English interface. But it is good that it is user-friendly (one day I tried to download something from China site, thats was crazy:)).


About recursive displaying - maybe sometimes it is useful but sometimes may confuse because if you lost some intermediate folder, you lost your target. And it is needed to parse all parts of path in order to get real target path.
But idea is interesting, maybe I'll add extra field for such thing (only real target, w/o intermediate paths). But this piece of stuff is needed for all kinds of objects - for real path displaying. I didn't understand completely your example but I think I got the thing.


About multi-files CAB - this feature exists very long - if you browse Win95 distributive, its contains a lot of such files, WinNT distributive unfortunately have most single-files CABs therefore it contains thousands of files. Only SPx.cab have multiple files. Also each MSI contains a lot of multi-files CABs.
Some years ago I used WinAce to create CABs, later PowerArchiver, today I use MsCab tool with my own GUI shell for it so I may call packing in background and even with admin rights. Also MS have CABSDK tool for packing such files. :wink:


Yeah, it's an interesting think - how we may to copy tooltip contents. I'm afraid, currently we can't. So, I think we need a parametrized command like COPYTOCLIP <user-defined string> where such a string may contain %P/%S/%L etc, '\n' chars and plugin fields. Seems that TC already has functions for creating such strings, so we need only a little command to copy it to clipboard. :)
Last edited by MVV on 2009-08-29, 08:28 UTC, edited 2 times in total.

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

Post by *Balderstrom » 2009-08-29, 08:16 UTC

[OT] I have CABSDK, it only packs single files...[/OT]

COPYTOCLIP would be perfect. The functionality to accept [plugintype.fields] for acquiring information on selected files: Now that you mention it, its definitely something that is sorely missing from ButtonBar or UserDefined em_'Actions... I wonder if Lefteous' "List to Clipboard" has that feature...

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

Post by *MVV » 2009-08-29, 08:31 UTC

Balderstrom wrote:I have CABSDK, it only packs single files...
Take a look on CABARC.exe utility:
Usage: CABARC [options] command cabfile [@list] [files] [dest_dir]
Balderstrom wrote:COPYTOCLIP would be perfect. The functionality to accept [plugintype.fields] for acquiring information on selected files: Now that you mention it, its definitely something that is sorely missing from ButtonBar or UserDefined em_'Actions... I wonder if Lefteous' "List to Clipboard" has that feature...
I think we should suggest this as internal command 'cause a lot of fields may be accessed only by TC internally. Here: http://www.ghisler.ch/board/viewtopic.php?p=183210

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

Post by *MVV » 2009-08-29, 16:30 UTC

I'd added field Obj_RealPath which shows path with expanded target links.

While experimenting, I had strange bug, path not always was being expanded fully. The reason was that if my current directory was reparse point, OS tells that object "F:" is reparse point (when backslash was missed).

I've found that version 1.0.0.42 not always expands all targets, this fixed in version 1.0.0.44 (now all path is reparsed after each next expand). If links form endless loop, expanding performs only 256 times (this is more than enough I thought).

Version 1.0.0.44 can't expand path if target begin with backslash. But I found out that Windows 7 also displays in properties such link target incorrectly, as if there was no slash. I.e. if symlinkd "F:\Test\Folder_SYM_Root" points to "\", Windows shows in its properties target "F:\Test", and if symlinkd "F:\Test\Folder_SYM_Root_11" points to "\11", target in properties is "F:\Test\11"!! :lol:

Version 1.0.0.48 is available here: http://files.wyw.ru/3877013 (CRC32: DED30084)

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

Post by *Balderstrom » 2009-08-30, 03:47 UTC

Cool :-)
Hovering over C:\Usr\<ME>\Application Data\¤TC
Junction points to: C:\Usr\Allxx\AppData\¤TotalCMD, VALID: Yes
Actual: C:\mntHD\HDa3\Allxx_Usr\AppData\¤TotalCMD
No need to resolve the HDDID //?/ string, so thats great.

I don't usually create recursive junctions - that point to a higher level of the path. I tried it recently and it causes bad recursion with subdir branchview hehe.

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

Post by *MVV » 2009-08-30, 07:50 UTC

Balderstrom wrote:I don't usually create recursive junctions - that point to a higher level of the path. I tried it recently and it causes bad recursion with subdir branchview hehe.
BTW it is so funny to search something in such folder loop with Windows Search. 8)

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

Post by *Balderstrom » 2009-08-30, 21:42 UTC

I found a small bug?
When hovering over C:\mntHD\HDa2, with
[=nl_info.Reparse Point Target]\n
[=ntlinks.Obj_Type] points to: [=ntlinks.RP_Target], VALID: [=ntlinks.RP_IsValid]\n
Actual: [=ntlinks.Obj_RealPath]
shows:
//?/Volume{*}
Mount Point points to: , VALID: YES
Actual: C:\mntHD\HDa2
While it's cool that the recursion doesn't bother resolving \\?\ Mount Points, NTLinks doesn't appear to resolve Mount Points at all.

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

Post by *MVV » 2009-08-31, 03:33 UTC

Balderstrom wrote:I found a small bug?
When hovering over C:\mntHD\HDa2, with
[=nl_info.Reparse Point Target]\n
[=ntlinks.Obj_Type] points to: [=ntlinks.RP_Target], VALID: [=ntlinks.RP_IsValid]\n
Actual: [=ntlinks.Obj_RealPath]
shows:
//?/Volume{*}
Mount Point points to: , VALID: YES
Actual: C:\mntHD\HDa2
While it's cool that the recursion doesn't bother resolving \\?\ Mount Points, NTLinks doesn't appear to resolve Mount Points at all.
NTLinks's [=ntlinks.Obj_RealPath] should expand all reparse points, mount points too. Because it just calls [=ntlinks.RP_Target] to expand them. So here a disappoint waits for you :)

NTLinks should resolve mount points in the form "\\?\Volume{bla-bla-bla}". Is it true that it shows slashes instead of backslashes to you? Maybe that's a reason then? If not, plz post exact mount point target here (from mountvol command, with all available paths). How did you get such mount point? I can't create mount point in the form "\\?\..." within mountvol command.

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

Post by *Balderstrom » 2009-08-31, 04:06 UTC

I think you missed what I was pointing out:
When hovering over C:\mntHD\HDa2, with
[=nl_info.Reparse Point Target]\n
[=ntlinks.Obj_Type] points to: [=ntlinks.RP_Target] ||, VALID: [=ntlinks.RP_IsValid]\n
Actual: [=ntlinks.Obj_RealPath]
shows:
//?/Volume{*}
Mount Point points to: ||, VALID: YES
Actual: C:\mntHD\HDa2
{*} I didn't list the HDID string, it shows up as normal - but only for NL_INFO, NTlinks wont display anything for a mountpoint, the entry is completely empty: notice there is no info at all before the ||, and the "Actual" shows what the non-mount is.

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

Post by *MVV » 2009-08-31, 05:43 UTC

I noticed that NL_Info couldn't resolve your mount point name too. I made an assumption that it is because your mount point has name with normal slashes instead of backslashes. Such mount point name is invalid within Windows.

I found that if my GetVolumePathNamesForVolumeNameStub can't resolve mount point path name, [=ntlinks.RP_Target] returns empty string. I'd fixed so that it will return unresolved mount point name (in the form of "\\?\..." in your case, as NL_Info does). I'll share new version 1.0.0.50 with this fix in the evening.

BTW, string "|[=ntlinks.RP_Target]|" is better for testing purposes than string "[=ntlinks.RP_Target] ||". :wink:

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

Post by *Balderstrom » 2009-08-31, 06:23 UTC

*GRIN* I put it in the Post only. my string was as noted in the first report... but it seemed to cause a mixup so I put a couple || in that I could refer to :-)

NL_Info did resolve the mount point, the same as junction.exe and mountvol.exe do. I just didn't copy my HardDriveID here. Not sure if anyone can do anything with that or not, but I didn't see any reason/need to post it public.
*BLINK* TC9 Added WM_COPYDATA and WM_USER queries for scripting.

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

Post by *MVV » 2009-08-31, 06:50 UTC

Anyway, your HDID is randomly-generated and doesn't contain any personal info.

NL_Info just resolves your mount point name ("//?/..."), but it doesn't resolve its path name ("X:\"). That's what I meant. It's the one thing I'm interesting now - why path name can't be resolved.

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

Post by *Balderstrom » 2009-08-31, 07:14 UTC

Those mountPoints have not been assigned a drive letter. They are soley mounted into a folder.
Thus I can partition my drives up without polluting the DriveLetter space with useless letters that are only used for other OS installs, or junctioned to for Data: "Program Files" + User's.

Prior to Vista (or WinXP) you can't junction to an UNC path or a HDID UNC path (on Win2K). Thus the workaround is mountvol "Folder" "//?/Volume{..HDID..}". Then you can junction to it.

So, C:\mntHD\HDa1, HDa2, and HDa3 were all mounted with mountvol.exe to a "//?/Volume{..HDID..}". Then you can junction thru them without the need of adding 3 more drive letters.

Post Reply