Infinite Loop with NTFS junctions

[braunr74]

On some Windows servers I'm experiencing an infinite loop:

c:\Documents and Settings\WINDOWS_ACCOUNT_HERE\AppData\Local\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Microsoft\Windows\History\History.IE5

or

c:\Users\XXXXXX\Application Data\Application Data\Application Data\Application Data\Application Data....

This is my workaround:

    private boolean isExcludedDirectory(String path) {
        if (isWindows && path.toUpperCase().indexOf("$RECYCLE.BIN") == 3)
            return true;

        //Infinite loop on some systems
        if (isWindows && path.toUpperCase().endsWith("\\APPLICATION DATA\\APPLICATION DATA"))
            return true;

        return (path.equals("/proc") || path.startsWith("/proc/")) || (path.equals("/sys") || path.startsWith("/sys/"))
                || (path.equals("/dev") || path.startsWith("/dev/")) || (path.equals("/run") || path.startsWith("/run/"))
                || (path.equals("/var/run") || path.startsWith("/var/run/"));
    }

[xeraph]

@braunr74 Would you test v2.1.0 release?

[IanSJones]

The issue appears to be that if the scanner is executed remotely then the permissions are higher than if it is run locally. When launched via PSExec, Invoke-Command or Ansible (WinRM) then the command can access c:\Documents and Settings

Invoke-Command -ComputerName -Credential -ScriptBlock {&dir "C:\Documents and Settings.NET v4.5\AppData\Local\Application Data"} will work

Invoke-Command -ScriptBlock {&dir "C:\Documents and Settings.NET v4.5\AppData\Local\Application Data"} will get permission denied.

[IanSJones]

Thanks for the workaround code - it spends about 90 secs lost in c:\Documents and Settings then moves on, improving the time it takes to complete from 3hr 15m to 10m

[xeraph]

@IanSJones Wow.. pretty much time savings!

[IanSJones]

yeh - we're just compiling an exe and will be running this against our 8,000 servers

[IanSJones]

Update - there is an official update out that avoids this "ReparsePoint" - better to use that than the fix above.