NTLinks + NTLinksMaker: NTFS links creation and information

[Boofo]

Read my edited post above.

[MVV]

That's Poltergeist.

I thought that via such link you don't need to enter any number. But this works only when you logged in, else you're just redirected to normal page.

Anyway, it should work. Note: if you see page with strange symbols instead of save dialog when you click download link in Opera, just save page as .CAB file.


New download sources: NTLinks at wincmd.ru / NTLinks at totalcmd.net

[MVV]

New version is released due to Unicode support requests.


NTLinks 1.0.0.72:
+ Unicode support
+ two new Unicode fields added: RP_TargetW, Obj_RealPathW
+ changed module base address
* for non-existent files type 'reparse point' was displayed

[MVV]

Little bug found that was caused by Unicode conversion.


NTLinks 1.0.0.74:
* returned wrong real path for symlinks with target started with backslash (relative to root) due to Unicode conversion

[VSB]

2MVV
Now, I'm writin packer plugin for creating Symboilic Links, HardLibks and Junctions

[MVV]

Maybe it will be more useful to write just separate tool for such task that will take list of selected items using %L?

I hope it will support Unicode.
Existing NTFS Links tool is good in all except Unicode support.

[VSB]

It will be ONLY Unicode, because UNC (\\?\c:\...) paths can be only in Unicode, and I'm writing with support of real long NTFS path (above 32000 characters).
Although, I don't want write/use tool, i suppose that plugin will be more useful for TC users.
And I'm planning to publish source after initial (main features) stage of development finish.
But I don't decided yet, what public license I should use. May be you can advice me&

[MVV]

I have no experience in comparing public licenses.

I can say where separate tool is more comfortable than packer plugin. To use tool we need to:
1. Select files/folders.
2. Press hotkey/buttonbar button.
3. Set options.
4. Start process.
To use packer plugin we need to:
1. Select files/folders.
2. Press Alt+F5/buttonbar button.
2a. Choose right plugin.
3. Set options.
4. Start process.

E.g. if I have a lot of additional plugins, I need to find corresponding plugin in drop-down list.
Or if I use some plugin frequently, TC keeps it as last used, but if there are more than one frequently used plugins, I need to choose right one from list every time I need to pack something.

BTW don't forget that creating symbolic links requires elevation! So if you're using separate tool, it may restart itself in elevated mode. But if it is written as plugin, it can't.

[VSB]

About About admin rights:
I'm thinking about COM Elevation Moniker
But I don't know how to implement all this((

[MVV]

I think separate application is much easier than COM:)))

[VSB]

But not so interesting.
It's just nothing to do here and now and I want to improve my C++ experience

[Balderstrom]

This may be a bug with Junction itself, but

NTLinks is indicates that the following the following Junction:

Junction: X:\_AUDIO_\_ARTIST_\Warlock ( Doro )\1984_Burning The Witches
Points2 : X:\_AUDIO_\_ARTIST_\Warlock ( Doro )\1984_Burning The Witches
Actual1 : X:\U\Admin\Documents\Music\Warlock\1984_Burning The Witches
VALID: Yes

Now Sysinternals Junction.exe indicates that:

Junction: \\?\X:\_AUDIO_\_ARTIST_\Warlock ( Doro )\1984_Burning The Witches
Points2 : X:\_AUDIO_\_ARTIST_\Warlock ( Doro )\1984_Burning The Witches

The junction is really invalid, as it USED to go to Actual1, but that path no longer exists.

[MVV]

Hm-m. Interesting. NTLinks calls GetFileAttributes to check if target is valid. And it asks Windows about reparse point target every time, it doesn't use any cache. So it tells Yes when Windows returns valud attributes for target.

As I see, you have a junction that points to itself. Am I right? How did you get such junction? And it is interesting how junction that points to itself can have another actual path...

Maybe you know how to reproduce this?

[Balderstrom]

It doesn't point to itself (or rather, I should say I didn't MAKE it point to itself). Before I deleted the old path, "X:\U\Admin\..." it used to point there.

I did an OS reinstall, the drive letters changed - that may of had something to do with it. I put the drive letters back afterwards, but that path was removed.
I'm not sure if it's reproduceable by just creating a junction, removing the path it points to and rebooting or not.

I have 4 such junctions in that particular folder as they all previously pointed to X:\U\Admin

Would just be nice if NTLinks could return invalid if where a junction points to is == itself

And here's one other of the group:
Where actual and points to are even the same heh.

in _ARTIST_\Warlock ( Doro )\
1985_HellBound
Poinst2 --> X:\_Audio_\_ARTIST_\Warlock ( Doro )\1985_Hellbound
Valid: Yes
Actual1: --> X:\_Audio_\_ARTIST_\Warlock ( Doro )\1985_Hellbound

[MVV]

It appears from what I have seen over the last while, when you delete the path that a junction points to, the junction will no longer point there. It will now point to itself. and attempts to parse it will return a valid path, but wont go anywhere.

When you delete target folder, junction is still points to that folder, but you can't enter it since it is invalid. Its target is not changed to its own path in such case until someone change it.

Would just be nice if NTLinks could return invalid if where a junction points to is == itself

Problem is that recursions won't be resolved here. E.g. you have junction 1 that points to junction 2 that points to junction 1 (or even more levels). To check if junction is valid you need to retrieve actual path - but it is not so quick procedure (it uses a loop that checks every name in path). RP_Valid field returns Yes when target folder exists - in your case it really exists. Maybe you need some other field here - 'points to itself'.

And here's one other of the group:
Where actual and points to are even the same heh.

BTW every usual junction has same actual path and target - if it doesn't point to folder that is inside of other reparse point.
But I don't know who changed theese junctions so they now point to themselves...