Shuery
42f02d0eca
16 个没有前缀的公共函数补上 BakNRet（Write-Log → Write-BakNRetLog、Resolve-BackupEntry → Resolve-BakNRetBackupEntry、Find-ChildDirectoryByName → Find-BakNRetChildDirectoryByName 等）， 另外把全仓的 Baknret 统一成 BakNRet（47 个文件、940 处、65 个定义文件重命名）。 这不是审美问题：静态分析直接拓出一条实据 —— Write-Log 与本机某个已装模块导出的命令 **重名**（PSAvoidOverwritingBuiltInCmdlets），而重名的后果是导入两个模块时有一方的命令被 静默遮蔽。补前缀正是这条规则的解法，改名后它归零。 为什么敢做这个规模：PowerShell 的函数名解析大小写不敏感，所以 Baknret → BakNRet 在功能 上是零风险；真正要验证的是 16 个补前缀的调用点，而 276 个断言几乎覆盖了每个函数。另外 "名字与文件名一致"这条不变式有断言盯着（加载器点源的文件集合 vs 磁盘）。 踩到并记下的坑：Windows 文件系统大小写不敏感，所以**只改大小写**的重命名会被 Move-Item 当成同一个文件而静默跳过 —— 同一批里同时改了名字的那 16 个文件却成功了，于是"看起来能跑"。 最后用"先移到临时名、再移到目标名"的两步走解决，判断与替换全部改用显式大小写敏感的形式 （-creplace / -cmatch）。 顺带把名录指纹缓存从 MD5 换成 SHA256（PSAvoidUsingBrokenHashAlgorithms）：它只是缓存键， 没有兼容负担。 验收：test.ps1 9/9 全绿（7 与 5.1）、100 个文件两版解析零错、276 个断言全过、 构建工具仍能合回单文件（3300 行）。
29 lines
1.1 KiB
PowerShell
29 lines
1.1 KiB
PowerShell
function Remove-BakNRetArchiveStaging {
|
|
<#
|
|
.SYNOPSIS
|
|
安全拆掉暂存目录：先手工摘掉 junction，再删剩下的普通文件 / 目录。
|
|
|
|
.DESCRIPTION
|
|
绝不能直接 `Remove-Item -Recurse` 了事：那会顺着 junction 走进真实数据里。
|
|
这里自己走一遍目录树，遇到连接点只删连接点本身。
|
|
#>
|
|
param([string]$Root)
|
|
|
|
if (-not $Root -or -not (Test-Path -LiteralPath $Root)) { return }
|
|
|
|
$pending = New-Object System.Collections.Generic.Stack[string]
|
|
$pending.Push($Root)
|
|
while ($pending.Count -gt 0) {
|
|
$current = $pending.Pop()
|
|
foreach ($child in @(Get-ChildItem -LiteralPath $current -Force -ErrorAction SilentlyContinue)) {
|
|
if ($child.LinkType -eq 'Junction' -or $child.LinkType -eq 'SymbolicLink') {
|
|
Remove-BakNRetJunction -Path $child.FullName
|
|
continue
|
|
}
|
|
if ($child.PSIsContainer) { $pending.Push($child.FullName) }
|
|
}
|
|
}
|
|
|
|
Remove-Item -LiteralPath $Root -Recurse -Force -ErrorAction SilentlyContinue
|
|
}
|