gpt4 book ai didi

powershell - 奇怪的 Copy-Item powershell 行为

转载 作者:行者123 更新时间:2023-12-03 16:43:25 25 4
gpt4 key购买 nike

我在 powershell 方面还是有点新手(来自 vbscript),我已经有一段时间没有做任何太严肃的事情了,所以如果代码没有达到它应有的优雅,我提前道歉.

场景是这样的:

我们使用的系统每半小时在一个目录中创建一个文件夹,在这些子文件夹中可以创建图像文件(它们在子文件夹中是不同的名称,但在子文件夹中是相同的约定,因此 SubFolderA 可能包含 picture1.jpg , picture2.jpg, picture3.jpg,但其他子文件夹也可能如此。

我需要监控整棵树,每当创建 JPG 文件时,将其复制出来,根据日期/时间/秒重命名并将其放在“平面”文件夹中。

在下面的代码中,行为在第一个文件夹上按预期工作(我可以生成多个文件,它将全部复制),但是当一个文件出现在下一个文件夹中时,它说它正在运行副本,但随后挂起。我没有从脚本中得到任何错误/反馈。

脚本在“我正在运行此副本”时停止,但没有其他任何反应,如果我重新启动脚本,它会正常运行,直到更改出现在第二个文件夹中。它可以是第一次发生更改的任何文件夹,之后的任何文件夹似乎都失败了。

我觉得我在处理事件的行为上做错了什么,但我对它的理解还不够深入。如果仅在一个文件夹中发生更改,代码本身似乎可以正常运行。

目录树看起来像:

X:\PicsSource
X:\PicsSource\Folder 1\
X:\PicsSource\Folder 2\
X:\PicsSource\Folder 3\

我还应该提一下,源将是网络共享,目标最初是本地的,但将来也可能是网络共享。对于我的测试,源和目标都是网络共享(在同一台服务器上),脚本在另一台机器上执行。

每个文件夹中有很多文件,但我只对 JPG 感兴趣。

我目前的代码:

Unregister-Event -SourceIdentifier FileCreated -ErrorAction SilentlyContinue
$folder = 'X:\PicsSource\' #Folder to monitor
$destination = 'X:\PicsDest\' #Folder to copy files too
$filter = '*.jpg' #Set this for filtering of file types


$fsw = New-Object IO.FileSystemWatcher $folder, $filter -Property @{
IncludeSubdirectories = $true
NotifyFilter = [IO.NotifyFilters]'FileName, LastWrite'
}



$onCreated = Register-ObjectEvent $fsw Created -SourceIdentifier FileCreated -Action {
$path = $Event.SourceEventArgs.FullPath
$name = $Event.SourceEventArgs.Name

$newname = get-item $path | Select @{Name="CreationTime";Expression= {"{0:yyyy}-{0:MM}-{0:dd}@{0:HH}{0:mm}_{0:ss}" -f ([DateTime]$_.CreationTime)}}
#Write-host $newname
$newname = $newname -replace "@{CreationTime="
$newname = $newname -replace "}"
#Write-Host $newname
#Write-Host $destination
#Write-Host $path
$finaldest = $destination + $newname
$finaldest = $finaldest + ".JPG" | Out-String
$finaldest = $finaldest.Trim()
write-host $finaldest
Copy-Item -path $path -Destination $finaldest -Force -Verbose
}

创建时间字符串有点乱,但我相信它的功能(很高兴看到改进!)

提前致谢,我很想解决这个问题:)

干杯,马特

最佳答案

我的猜测是您处理创建的事件的脚本 block 正在抛出异常,并且 FileSystemWatcher 再也不会调用它。来自该事件的任何未处理的异常将导致 FileSystemWatcher 不再调用您的事件。

我的下一个猜测是调用的事件存在时间问题。当在目录中创建文件时会触发 Created 事件,因此该事件可能会在写入数据和关闭文件之前触发。也许文件夹 2 有一些非常大的文件,但写入速度很慢?

无论如何,一种常见的解决方案是在写入文件时出现错误时简单地重试文件复制。查看以下事件代码是否适合您:

$onCreated = Register-ObjectEvent $fsw Created -SourceIdentifier FileCreated -Action {
$path = $Event.SourceEventArgs.FullPath

$newname = (Get-Item $path).CreationTime.ToString("yyyy-MM-dd@HHmm_ss_fff")
$finaldest = $destination + $newname + ".JPG"

$copied = $false
$retriesLeft = 10
while(-not $copied -and ($retriesLeft -gt 0)) {
try {
Copy-Item -path $path -Destination $finaldest -Force -Verbose
$copied = $true
} catch {
Start-Sleep -Milliseconds 500
--$retriesLeft
}
}
if (-not $copied) {
# log an error with $path and $finaldest
}
}

基本上,它所做的是尝试复制,如果失败,它将休眠 500 毫秒,然后重试。在永久放弃之前,它最多可以重试 10 次。我还对生成的文件名添加了毫秒数,因为在我的测试中,当粒度为秒级时,快速传入的文件会被覆盖。

关于powershell - 奇怪的 Copy-Item powershell 行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19249503/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com