On a Windows Server 2008 R2 VM, I upgraded PowerShell to v3 hoping to take advantage of the Get-ChildItem (gci) performance improvement. This line ran without error in v2:
$search = gci $dir -recurse -exclude "*.mdf" | where {$_.length -gt 100mb}
After upgrading to v3, why does the same line give this error? The $dir value is unchanged.
gci : 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 line:1 char:11
+ $search = gci $dir -recurse -exclude “*.mdf” | where {$_.length -gt 100mb}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ReadError: (\server.domain…DETAILS 1.0.prt:String) [Get-ChildItem], PathTooLongException
+ FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
There is no change after applying Windows Updates and rebooting. I took a snapshot of the VM before upgrading PowerShell, so I have the luxury of toggling back and forth easily.
$errorActionPreference is Continue in both v2 and v3.
$search.count is 8 in both v2 and v3, so I’m not super concerned about missing stuff, but would like to understand the change in behavior.
I tried addding -force in v2, saw similar PathTooLong errors, and .count is 10. After adding -force in v3, .count was 9. I then reverted to v2 and again found 10 files with -force. It’s nevertheless possible that changing data under $dir could explain the .count difference, but in our environment, changing data couldn’t realistically explain the consistent presence of PathTooLong errors in v3, but not v2. Now that my curiosity has gotten the better of me, I’m hoping someone has a lead on this mystery and will spare me the error handling which, I admit, might offer more clues.
FWIW, the usage documentation on TechNet says it applies to both v2 and v3. The -Force parameter’s default value is False.
Some background on PowerShell and MAX_PATH from the v1 days.
On a Windows Server 2008 R2 VM, I upgraded PowerShell to v3 hoping to take advantage of the Get-ChildItem (gci) performance improvement. This line ran without error in v2:
$search = gci $dir -recurse -exclude "*.mdf" | where {$_.length -gt 100mb}
After upgrading to v3, why does the same line give this error? The $dir value is unchanged.
gci : 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 line:1 char:11
+ $search = gci $dir -recurse -exclude “*.mdf” | where {$_.length -gt 100mb}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ReadError: (\server.domain…DETAILS 1.0.prt:String) [Get-ChildItem], PathTooLongException
+ FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
There is no change after applying Windows Updates and rebooting. I took a snapshot of the VM before upgrading PowerShell, so I have the luxury of toggling back and forth easily.
$errorActionPreference is Continue in both v2 and v3.
$search.count is 8 in both v2 and v3, so I’m not super concerned about missing stuff, but would like to understand the change in behavior.
I tried addding -force in v2, saw similar PathTooLong errors, and .count is 10. After adding -force in v3, .count was 9. I then reverted to v2 and again found 10 files with -force. It’s nevertheless possible that changing data under $dir could explain the .count difference, but in our environment, changing data couldn’t realistically explain the consistent presence of PathTooLong errors in v3, but not v2. Now that my curiosity has gotten the better of me, I’m hoping someone has a lead on this mystery and will spare me the error handling which, I admit, might offer more clues.
FWIW, the usage documentation on TechNet says it applies to both v2 and v3. The -Force parameter’s default value is False.
Some background on PowerShell and MAX_PATH from the v1 days.
I know that the PathTooLongException is not specific to PowerShell. It is thrown by the Win32 APIs that are called behind the scene. If you must work with long paths, you might find out if PowerShell will allow you to make use of the Unicode versions of the Win32 APIs instead. See here for information
As for why version 2 did not throw the error, I can only presume that version 2 had “better” internal handling of the exception.