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
964 B
PowerShell
29 lines
964 B
PowerShell
function Write-BakNRetAtomicText {
|
|
<#
|
|
.SYNOPSIS
|
|
原子写一个文本文件（先写 .tmp，再替换）。
|
|
#>
|
|
param(
|
|
[Parameter(Mandatory = $true)][string]$Path,
|
|
[AllowEmptyString()][string]$Text = ''
|
|
)
|
|
|
|
$directory = Split-Path -Parent $Path
|
|
if ($directory -and -not (Test-Path -LiteralPath $directory)) {
|
|
New-Item -ItemType Directory -Path $directory -Force | Out-Null
|
|
}
|
|
|
|
$temp = "$Path.tmp"
|
|
[System.IO.File]::WriteAllText($temp, $Text, $script:LogEncoding)
|
|
|
|
if (-not (Test-Path -LiteralPath $Path)) {
|
|
Move-BakNRetArchiveIntoPlace -TempPath $temp -DestinationPath $Path
|
|
return $Path
|
|
}
|
|
|
|
# 目标已存在：用 File.Replace。失败时旧内容完好、.tmp 留着便于排查（两版实测一致）——
|
|
# 这正是"宁可这次没换成，也不能让目标消失"。
|
|
[System.IO.File]::Replace($temp, $Path, [NullString]::Value)
|
|
return $Path
|
|
}
|