NTLinks + NTLinksMaker: NTFS links creation and information

[MVV]

Thanks for that description.

Let me describe something too:)
If I have a volume, GetVolumePathNamesForVolumeName function returns all available mounted paths for it. Usually first of them is assigned drive letter, so RP_Target returns it. But if no drive letter assigned but some path is assigned, RP_Target will return this path (in theory).

According to this, your "//?/Volume{...}" volume has no assigned drive letter but has mounted path, in your case it is "C:\mntHD\HDa1" for example. So, I think that RP_Target should return this path instead of just volume name.

BTW, if your volume has the only mounted path "C:\mntHD\HDa3", it will be leaved as is by Obj_RealPath if mounted path may be resolved. But currently I think you will get real path like "//?/Volume{...}\Allxx_Usr" if we leave it as is. I can't find any info about "//?/" prefix in MSDN, it only uses "\\?\" prefix. That's why I'm interesting why your path contains forward slashes - if replacing them to backslashes will help to resolve mounted path, this should be done.

[Balderstrom]

Oh, that might just be a typo, I hand wrote them

I installed TortoiseSVN to double check on something I had stated about a previous version, and it wont work w/o a reboot, and it modified my "%PATH%" variable and now everything that I had added to my PATH previously is completely hosed and wont work. And I have too much open atm to bother rebooting to fix the PATH and continue checking on that TortoiseSVN nonsense. Thus my junction.exe isn't working ... the system can't find its path any longer. And sometimes I work in Cygwin Bash Shell... so my brain interchanges / and \
They are \\?\ - sorry.

[MVV]

Hmm, if they are "\\?\", I don't understand. With such volume mount points NTLinks should work normally (for my mount points it works). I.e. I had removed my flash drive's label and created a mount point (i.e. "F:\e\0"), and [=nlinks.RP_Target] returns "F:\e\0" string - first volume mounted path.

I'd fixed another little issue which occurs if volume has no letter assigned and path to be expanded contains mounted path for this volume for example. In this case endless loop occurs because mount point path and its target path are the same:) my previously added loops counter allows to avoid it but when loops count expires, not all RPs may be expanded. So, now I check separately if RP's path and its target are the same and break loop.

As I said, last release will be shared in the evening.

[Balderstrom]

That's still a drive letter though...
These are purely mounted volumes. They have no drive letters at all.

Code: Select all

 \\?\Volume{a0582f75-8dd7-11de-a27e-806d6172696f}\
     C:\

 \\?\Volume{a0582f76-8dd7-11de-a27e-806d6172696f}\
     C:\mntHD\HDa1\
     D:\

 \\?\Volume{a0582f77-8dd7-11de-a27e-806d6172696f}\
     C:\mntHD\HDa2\

 \\?\Volume{a0582f78-8dd7-11de-a27e-806d6172696f}\
     C:\mntHD\HDa3\

 \\?\Volume{3f6da0a4-8df7-11de-ab0a-00e018998877}\
     L:\

 \\?\Volume{3f6da0a5-8df7-11de-ab0a-00e018998877}\
     P:\

 \\?\Volume{3f6da0a6-8df7-11de-ab0a-00e018998877}\
     *** NO MOUNT POINTS ***

 \\?\Volume{3f6da0a7-8df7-11de-ab0a-00e018998877}\
     M:\

 \\?\Volume{3055401a-8df3-11de-bbb0-806d6172696f}\
     G:\

[MVV]

Ah... I'm don't understand...

If your volume has no mount points, so it is unaccessible at this moment at all. So you can't pass it to NTLinks because you have nothing to hover with your mouse:) And you can't check how NTLinks works with it=)

If volume has at least one mounted path, so it has this path, and you may achieve some info about this path through NTLinks/NL_Info. In this case both plugins should return this mounted path.

So, for your "\\?\Volume{3f6da0a6-8df7-11de-ab0a-00e018998877}\" volume you can't get any info.
But for your "\\?\Volume{a0582f77-8dd7-11de-a27e-806d6172696f}\" volume you may get info through folder "C:\mntHD\HDa2". In my mind both plugins should show you "C:\mntHD\HDa2" as mount point target 'cause it is the first available path for this volume.

Stop, you have Win2K! So, you have no GetVolumePathNamesForVolumeName available! And both plugins may just check if drive letter for your volume exists! Now I got it! As I wrote, I'd fixed the issue when GetVolumePathNamesForVolumeNameStub returns nothing. In following release [=ntlinks.RP_Target] should work as [=nl_info.Reparse Point Target].

Or it will be better just to return mount point source path if its volume path can't be resolved? If Yes, you will see "C:\mntHD\HDa2\" as root for all sub-entries of it, if No, you will see "\\?\Volume{a0582f77-8dd7-11de-a27e-806d6172696f}\" as root in [=ntlinks.Obj_RealPath]. BTW, "C:\mntHD\HDa2" is correct mount point target 'cause no other targets available - anyway it is a root directory of your unlucky volume

Me thinking how your mountvol.exe gets info about mount paths if your OS has no GetVolumePathNamesForVolumeName function...

Ouch, I found a function FindFirstVolumeMountPoint, I'll play with it, seems that it is the easier way than drive letters enumeration!
Unfortunately stupid FindFirstVolumeMountPoint function requires admin rights.
Yeah, I found mounvtol.exe from Windows 2000, it uses FindFirstVolumeMountPoint function and w/o admin rights may only resolve drive letters assigned to volumes. Me can't understand why this information function requires admin rights...


I thought and choose Yes. But also added FindFirstVolumeMountPoint support (only admin rights, works strangely).
NTLinks version 1.0.0.54: http://files.wyw.ru/3881678 (MD5: 1F996BA9F736B3A4A6F6DE3E26F2583A)

[Balderstrom]

Hovering over "AutoHotKey" in:
C:\Usr\<ME>\Application Data\AutoHotKey, with

[=nl_info.Reparse Point Target]\n
[=ntlinks.Obj_Type] points to: [=ntlinks.RP_Target], VALID: [=ntlinks.RP_IsValid]\n
Actual: [=ntlinks.Obj_RealPath]

C:\mntHD\HDa3\Allxx_Usr\AppData\AutoHotKey
Junction points to: C:\mntHD\HDa3\Allxx_Usr\AppData\AutoHotKey, VALID: Yes
Actual: C:\mntHD\HDa3\Allxx_Usr\AppData\AutoHotKey

Which is all fine, that makes sense how both are resolving the path's. The only issue which I think is clear now, when hovering over an actual MountPoint it would be most useful be able to retrieve what the Volume{*} is, even if the volume has an assigned DriveLetter.
Since a different filter could be applied like:

[tc.file type] = reparse point
[ntlinks.Obj_Type] = Mount Point

Thus something like [ntlinks.VolumeName] to return the Volume{..HDID..}

OT: I could run WinXP, or possibly my downloaded Win7 32bit|64bit (which I plan to, to see if my Nvidia nForce2.5 board will work or not). I honestly just find Win2K more stable - though there are the odd program conflicts.

[MVV]

I think if you need info about volume your MP points to, you may run mountvol with admin rights

[Postkutscher]

2MVV
Does your last changes in the plugin affects >WinNT5.1 systems too?

[Balderstrom]

True, I initially mentioned this, as NL_Info does show the Volume{*VolumeName*} of a MountPoint when it's not a DriveLetter and NTLinks does not.

And earlier in the thread you asked for feedback/suggestions. I thought [ntlinks.VolumeName] was an interesting suggestion -- not that I don't have other means to find out what the VolumeName is.

[MVV]

2MVV
Does your last changes in the plugin affects >WinNT5.1 systems too?

No, you won't see any differences (just more accurate low-deep RP expanding 'cause of some loop avoiding). In Windows XP and later first volume mount point may be always achieved by GetVolumePathNamesForVolumeName function w/o admin rights. So, if you have a volume with drive letter and with mounted folder, you will see its letter as MP target (first mounted path), and if it has no drive letter, but has more than one mounted folder, you will see path to first mounted folder as MP target (in NT 5.0 plugin will return path to current mounted folder in such case).

True, I initially mentioned this, as NL_Info does show the Volume{*VolumeName*} of a MountPoint when it's not a DriveLetter and NTLinks does not.

And earlier in the thread you asked for feedback/suggestions. I thought [ntlinks.VolumeName] was an interesting suggestion -- not that I don't have other means to find out what the VolumeName is.

For mount point "C:\mntHD\HDa2" its path is fully valid mount point target (the only thing that it may be not first).
I don't want to add special field for only specific file type. Mount point's volume GUID is not so frequently required and not so easy readable.

Well, I've added a new output mode for mount points (affects real path too) - symbolic. In this mode volume names are not expanded to human-readable paths. Again, this wouldn't affect on currently possible field setups, so you won't see any difference until you change it manually. Enjoy!


NTLinks 1.0.0.56: http://files.wyw.ru/3882177 (MD5: 16D3A5155BA62447B02CCB66C8023E1C)

[MVV]

I couldn't edit previous post, so I type new link to plugin here. There is no changes (no more suggestions ), only URL was added into archive.


NTLinks 1.0.0.56: http://files.wyw.ru/wyw_file?id=3998836 (MD5: 01D9EA86F58778A0885EBFBB6B9D4FD6)

[Boofo]

2MVV,

I am not able to get the file from that link. I have tried Opera and IE8 and get nothing.

[Balderstrom]

Works fine for me Boofo.
Type in the number in the provided text field.
Click the button below it.
Click the link that appears afterwards: In the same area where the Number/TextField and button were.

[Boofo]

I know how to do it and did all that in both browsers and still got nothing.

Scratch that. It worked this time.

[Balderstrom]

@Boofo, I have Opera10 and just downloaded it...