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 行）。
17 lines
515 B
PowerShell
17 lines
515 B
PowerShell
function Remove-BakNRetJunction {
|
|
<#
|
|
.SYNOPSIS
|
|
只删连接点本身，绝不顺着它删到目标目录里去。
|
|
#>
|
|
param([Parameter(Mandatory = $true)][string]$Path)
|
|
|
|
if (-not (Test-Path -LiteralPath $Path)) { return }
|
|
try {
|
|
# Directory.Delete(path, recursive: $false) 删的只是重解析点，不碰目标内容
|
|
[System.IO.Directory]::Delete($Path, $false)
|
|
}
|
|
catch {
|
|
Remove-Item -LiteralPath $Path -Force -ErrorAction SilentlyContinue
|
|
}
|
|
}
|