we need infinite recursion detection or option to skip NTFS Junctions/symlinks for folders

[R-Adrian]

on modern Windows systems some folder paths from %USERPROFILE% are actually NTFS junction points to other folders under the same tree root...

this causes an infinite loop situation that is only broken when the constructed the file path name exceeds the maximum possible path length (256-ish characters)

for example:
%USERPROFILE%\Local Settings is actually a NTFS Junction to %USERPROFILE%\AppData\Local

in this folder we have another junction... and this is where the problem starts:
%USERPROFILE%\AppData\Local\Application Data is a NTFS junction that points back to ... %USERPROFILE%\AppData\Local
(yes.. a junction that points back to the parent of the junction... blame Microsoft.)
My OS here is Windows 10 1703, fully updated but the same OS behaviour is present on Windows 7 too.

Please add an option to skip NTFS Junctions/symlinks or add some recursive path loop detection logic when creating/verifying checksums.

I think an option to skip NTFS Junctions and NTFS symlinks (for folders only) would be much simpler.

[ZPNRG]

I haven't encountered this problem, but am using Windows 10 v1703 (latest build). I echo that this potential issue should be addressed in some form.

[R-Adrian]

even Win 10 1703 has this... it's done by design by Microsoft for compatibility with older programs that expect a different structure of the user profile folder.

please check the user profile folder on your computer and try to create a recursive checksum file for it.

HashCheck will "find" a lot more files than there are actually on disk because it follows NTFS folder junctions and symlinks.

[surfasb]

I think it should skip NTFS junctions and Symlink folders by default.

[JohnLGalt]

Having the option to allow / disallow following junctions would be most beneficial, IMO, with the caveat that by default it is disallowed.

[R-Adrian]

update: i have noticed that Microsoft has introduced a new group policy for Win10 in recent years that significantly alters the maximum possible file path length:

gpedit.msc -> computer -> administrative templates -> system -> filesystem -> Enable Win32 long paths

this policy, if enabled, coupled with HashCheck's bug of blindly traversing paths recursively means that the recursion depth is increased by a few orders of magnitude.... basically it becomes an (almost) never-ending loop (not quite infinite, but high enough to feel like an infinite loop)

[JohnLGalt]

Yummy. As if my ancient system doesn't have enough issues.

Seriously, though, I just cleanly installed 1903, and then joined the Insider Program and took the Skip Ahead build 18945 - and that setting is currently set to Not configured.

But it can be enabled - and with near disastrous effects with HC also installed.

[RchGrav]

Junctions should probably be skipped in general unless you override and force to follow them.. Why would you want to follow junctions when there is an actual folder taking you in most cases.. junctions are sometimes (typically?) for compatibility w/ previous (legacy) paths for compatibility.. For example, the \Users[username]\AppData\Local\Application Data\ folder links back to \Users[username]\AppData\Local\ <- This example is also recursing.

[JohnLGalt]

Well, I don't like accessing things like .ISOs in folders that are several layers down the chain - so I have those locations that I use often (for example, the folders where I store newly created Windows 10 Insider Preview .ISOs from UUPDUMP.ml) junctioned back to a single F:\ISOs\ folder for easy access.

As the contents of the folder F:\Storage\ISOs\OSs\Windows\10\ changes on a nearly weekly basis....

Yes, I know - I'm the exception to the rule - but as you can probably bet, those (and other files in a similar situation, whose parent folder I've junctioned to a shallow location) are also exactly the files that I will need to verify hashes on.....

[superbonaci]

There are soft and hard links, and also shared folders.