I’m trying to build a log with filepaths to items on our server that exceed 255 characters. This script works to log items as high as 351 Characters. (I have no idea how an employee was able to save these files, but there’s full on sentences in the file name/directory path).

The script is working, in that I’ve identified 780 files which exceed the acceptable path length for Microsoft PCs. But at the end of the script I get a bunch of errors suggesting this is NOT a complete list.

# The path to scan and the the lengths for (sub-directories will be scanned as well).
$pathToScan = "\Server"          #or "\ServerShare" 

# This must be a file in a directory that exists and does not require admin rights to write to.
$outputFilePath = "C:tempFilePathLengths.txt" 

$Drive = New-PSDrive "X" -PSProvider FileSystem -Root $pathToScan
$DriveLength = $pathToScan.Length

$writeToConsoleAsWell = $false   # Writing to the console will be much slower.
 
# Open a new file stream and write all the paths and their lengths to it.
$outputFileDirectory = Split-Path $outputFilePath -Parent

if (!(Test-Path $outputFileDirectory)) { New-Item $outputFileDirectory -ItemType Directory }
$stream = New-Object System.IO.StreamWriter($outputFilePath, $false)

# Starting effort before this caused errors, tried alternatives
# Get-ChildItem -Path $pathToScan -Recurse -Force | Select-Object -Property FullName, @{Name="FullNameLength";Expression={($_.FullName.Length)}} | Sort-Object -Property FullNameLength -Descending | ForEach-Object {

Get-ChildItem -Path "X:" -Recurse -Force | Select-Object -Property FullName, @{Name="FullNameLength";Expression={($_.FullName.Length)}} | Sort-Object -Property FullNameLength -Descending | ForEach-Object {
    If ($_.FullNameLength -gt 255) {
    $filePath = $_.FullName
    $length = $_.FullNameLength
    $string = "$length | $filePath"
     
    # Write to the Console.
    if ($writeToConsoleAsWell) { Write-Host $string }
  
    #Write to the file.
    $stream.WriteLine($string)
    }
}
$stream.Close()
Remove-PSDrive "X"

(I’ve censored out information by putting replacing text WITH ‘ScriptPath&Name’ – This is the path to the saved script being run.

‘FilePath that isn’t descriptive enough to actually identify the file’ replaced a specific file it had issue with, but doesnt have enough info to identify.)

Error Received:

Get-ChildItem : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
At ‘ScriptPath&Name’.ps1:17 char:1

• Get-ChildItem -Path “X:” -Recurse -Force | Select-Object -Property F …

•   + CategoryInfo          : ReadError: ('FilePath that isn't descriptive enough to actually identify the file' :String) [Get-ChildItem], PathTooLongException
    + FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
  
  
  
  

My goal is to identify ALL directory items that VEEAM/vmware may not correctly handle or recover when we migrate from Server 2012 to 2022. This way we can address them in bulk or individually. I’m open to ideas, but while I’m familiar with Visual Basic, Powershell is new to me.

Thank you!

I tried to log Get-ChildItems to identify files that may not RESTORE to the directory after we build a new server and recover from backups(Using our backup file to RESTORE to a new server). Files with a path greater than 255 characters or 260, or whatever… They don’t recover from backups. My script is able to easily identify files greater than the limit. But it still causes 20 or so file errors saying the file name is too long. Despite ALL the results being file name/paths too long.

I’ve attempted to enable Long Paths in the registry.
I attempted using a temporary PSDrive to truncate the filepath during discovery.

My concern is that I’ve been able to log items with this revised code up to 350 characters, but it’s still getting errors beyond that of path’s too long.

I am hoping to have a clear analysis of files that need renaming, because the filepath is too large.

Thank you!