PSFolderSize

PSFolderSize copied to clipboard

Hi!

I tried this module today. It's really great.

One small problem though. I noticed it's showing ~2x the size of a particular folder when compared to the Explorer's Properties dialog. Upon inspecting, I found out that the folder contained symlinks to some other folders.

PSFolderSize should ideally ignore symlinked folders and should not recurse into them to add their size to the output. Otherwise, it's nice!

Hello! I will take a look at this in the coming week. Thanks for the report.

There are number of directories in the users profile directory which are sym links too, like c:\users<user>\Local Settings and c:\users<user>\AppData\Local, and that really throws off the sizes, as well as the time it takes to walk through several hundred user accounts.

For better or worse and without thinking about any other repercussions, I made the following change in Get-FolderSize.ps1 around like 280, and closed the block around line 390.

         **if ($folder.Attributes.ToString().Contains("ReparsePoint") -eq "True") {
            Write-Verbose "...skipping $fullPath, it's a ReparsePoint"
        } else {**

            Write-Verbose "Working with [$fullPath]..."            

            #Get folder info / sizes

Thanks for this, I will take a look, do some more testing, and see about implementation.

@gngrninja I'd suggest taking some reference from the linked PowerColorLS issue for implementation details too :)

I've finally gotten around to this - I believe it was a simple fix, too. Please try out https://github.com/gngrninja/PSFolderSize/commit/adf71c7ed046f5eb2fdc2028aebb12ddcab666f8 and let me know!

Hi!

It seems the fix only works in PowerShell Core?

These are my results:

• PowerShell 7.2.0

• PowerShell 5.1

• This is the output of a crazy-fast disk utility written in Golang - gdu

---

The PowerShell 7.2.0 and gdu outputs are correct.

However, the PowerShell 5.1 output seems to be problematic. The folder sizes aren't just double - they're multiplied many times over in some cases (presumably due to presence of multiple sym/hard links).

I'll have to see how 5.1 handles things as well. Thanks for the heads up!