Not only was able to use robocopy to get a listing of all files regardless of the depth of the folder structure, but I am also able to get the total count of all files and the total size in bytes. $object = New-Object PSObject -Property = $item Something like this would work and you can then use Caption as the source path. If running a scan against folders that might be using mount points, it would be a good idea to use Win32_Volume to get the paths to those mount points. I use the /XJ so I do not get caught up in an endless spiral of junction points that eventually result in errors and false data. Wait time between retries: default is 30 seconds.ĮXclude Junction points. Number of Retries on failed copies: default 1 million. Include source file Time Stamps in the output. No Directory List – don’t log directory names.
Include Full Pathname of files in the output. List only – don’t copy, timestamp or delete any files. So what do the switches do you ask? The table below will explain each switch. \PowerShellScripts NULL /L /S /NJH /BYTES /FP /NC /NDL /XJ /TS /R:0 /W:0Īs you can see, regardless of the total characters in the path, I can easily see all of the data I was hoping to see in my original query now available. Using some switches in robocopy, we can list all of the files along with the size and last modified time as well as showing the total count and size of all files. Because robocopy is not a windows specific utility, it does not adhere to the 260 character limit (unless you want to using the /256 switch) meaning that you can set it off and it will grab all of the files and folders based on the switches that you use for it. So how do we accomplish this feat? The answer lies in a freely available (and already installed) piece of software called robocopy.exe. What I a going to do is show you how to get around this issue and see all of the folders and files as well as giving you a total size of a given folder. I won’t go into the technical reason for this issue, but you can find one conversation that talks about it here. Seeing this message means heartburn because now we are unable to get a good idea on just how many files (and how big those files are) when performing the folder query.Ī lot of different reasons for what causes this issue are available, such as users that are mapped to a folder deep in the folder structure using a drive letter and then continuing to build more folders and sub-folders underneath each other. The infamous PathTooLongException that occurs when you hit the 260 character limit on a fully qualified path. \PowerShellScripts | Select -Expand Fullname