PowerShell v3中的Get-ChildItem出现PathTooLong错误,但v2中没有 [英] PathTooLong error with Get-ChildItem in PowerShell v3, but not v2

查看:87
本文介绍了PowerShell v3中的Get-ChildItem出现PathTooLong错误,但v2中没有的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Windows Server 2008 R2 VM上,我将PowerShell升级到v3,希望能够利用 Get-ChildItem (gci)性能改进。该行在v2中运行没有错误:

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}

升级到v3后,为什么同一行显示这个错误? $ dir 的值保持不变。

After upgrading to v3, why does the same line give this error? The $dir value is unchanged.


gci:指定的路径,文件名,或两者都太长。完全限定的文件名必须少于260个字符,目录名的
必须少于248个字符。
在第1行:char:11
+ $ search = gci $ dir -recurse-排除 * .mdf |其中{$ _。length -gt 100mb}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo:ReadError:(\server.domain ... DETAILS 1.0.prt:String)[Get-ChildItem],PathTooLongException
+ FullyQualifiedErrorId:DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand

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

应用Windows更新并重新启动后没有任何变化。在升级PowerShell之前,我为VM制作了快照,因此可以轻松地来回切换。

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 在v2和v3中都是 Continue

$errorActionPreference is Continue in both v2 and v3.

$ search.count 在v2和v3中均为8,因此我不太担心丢失的东西,但想了解行为的变化。

$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.

我尝试在v2中添加 -force ,看到类似的PathTooLong错误,并且 .count 为10。添加<$ c v3中的$ c> -force , .count 为9。然后恢复到v2,再次找到10个文件,其中的 -force 。但是,在 $ dir 下更改数据可能可以解释 .count 的差异,但是在我们的环境中,更改数据无法在第3版中而不是在第2版中现实地解释PathTooLong错误的一致性。现在,我的好奇心得到了改善,我希望有人能在这个奥秘上遥遥领先,并且可以避免给我带来更多线索的错误处理。

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,使用TechNet上的使用文档表示适用于v2和v3。 -Force 参数的默认值为False。

FWIW, the usage documentation on TechNet says it applies to both v2 and v3. The -Force parameter's default value is False.

在PowerShell上使用某些背景,从v1开始使用 MAX_PATH

Some background on PowerShell and MAX_PATH from the v1 days.

Windows Server 2008 R2上VM,我将PowerShell升级到v3,希望利用 Get-ChildItem (gci)性能改善。该行在v2中运行没有错误:

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}

升级到v3后,为什么同一行显示这个错误? $ dir 的值保持不变。

After upgrading to v3, why does the same line give this error? The $dir value is unchanged.


gci:指定的路径,文件名,或两者都太长。完全限定的文件名必须少于260个字符,目录名的
必须少于248个字符。
在第1行:char:11
+ $ search = gci $ dir -recurse-排除 * .mdf |其中{$ _。length -gt 100mb}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo:ReadError:(\server.domain ... DETAILS 1.0.prt:String)[Get-ChildItem],PathTooLongException
+ FullyQualifiedErrorId:DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand

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

应用Windows更新并重新启动后没有任何变化。在升级PowerShell之前,我为VM制作了快照,因此可以轻松地来回切换。

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 在v2和v3中都是 Continue

$errorActionPreference is Continue in both v2 and v3.

$ search.count 在v2和v3中均为8,因此我并不担心丢失的东西,但想了解行为的变化。

$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.

我尝试在v2中添加 -force ,看到类似的PathTooLong错误,并且 .count 为10。添加<$ c v3中的$ c> -force , .count 为9。然后恢复到v2,再次找到10个文件,其中的 -force 。但是,在 $ dir 下更改数据可能可以解释 .count 的差异,但是在我们的环境中,更改数据无法在第3版中而不是在第2版中现实地解释PathTooLong错误的一致性。既然我的好奇心得到了改善,我希望有人能在这个谜团中占主导地位,并让我免于错误处理,我承认这可能会提供更多的线索。

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,使用TechNet上的使用文档表示适用于v2和v3。 -Force 参数的默认值为False。

FWIW, the usage documentation on TechNet says it applies to both v2 and v3. The -Force parameter's default value is False.

在PowerShell上使用某些背景,从v1开始使用 MAX_PATH

Some background on PowerShell and MAX_PATH from the v1 days.

推荐答案

我知道PathTooLongException并非特定于PowerShell。它由在后台调用的Win32 API抛出。如果必须使用长路径,则可能会发现PowerShell是否允许您改用Win32 API的Unicode版本。 有关信息,请参见此处

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

至于为什么第2版没有引发错误,我只能假定第2版具有更好的功能内部处理异常。

As for why version 2 did not throw the error, I can only presume that version 2 had "better" internal handling of the exception.

这篇关于PowerShell v3中的Get-ChildItem出现PathTooLong错误,但v2中没有的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆