我们有一个脚本，该脚本原本用于将日志文件从服务器移至本地存储库。结果发现，该脚本的作者在目标位置意外添加了一个撇号：
MOVE /y "C:\XXX\XXX\XXX\audit.*.log" "\\[FQDN]\XXX`$\XXX\XXX\XXX"
（注意美元符号前的撇号）
日志文件已从服务器上消失，大概是因为打字错误，它们没有出现在存储库服务器中。
监控服务器的第三方供应商也提到，硬盘似乎快满了，这与丢失的日志文件的大小一致（过去 6 周，每天每个文件约 500MB）。
问题：这些丢失的日志文件可以恢复吗？Windows 是否将 MOVE 操作中的文件存储在隐藏/临时文件夹中的某个位置，还是它们永远消失了？目前，我并不担心硬盘空间，因为我已经纠正了错误。如果可能的话，我想恢复日志。
服务器和存储库的操作系统都是 Windows Server 2019（我认为）。
答案1
我们有一个脚本，该脚本原本用于将日志文件从服务器移至本地存储库。结果发现，该脚本的作者在目标位置意外添加了一个撇号：
撇号可能不一定是偶然的；它是 PowerShell 中的“转义”字符（例如，"`n"在 PS 中的含义与其他语言中的含义类似"\n"，都扩展为换行符）。
$由于 PowerShell 字符串将扩展 $variables，因此在需要保留文字“$”（例如）的前面放置转义字符是正常的"foo`$bar"，即使在您的特定示例中不会发生变量扩展，反引号仍然具有相同的结果，即产生"`$"文字美元符号（这可能是您想要的）。
Windows 是否将 MOVE 操作中的文件存储在隐藏/临时文件夹中的某个位置，
不会。但是，在从源复制到目标成功之前，它也不会删除原始文件。如果脚本确实将文件移动到不存在的共享，则 PowerShell“Move-Item”和 Cmd.exe“MOVE”都会在无法创建输出文件后停止，而不会删除任何内容。
服务器磁盘空间逐渐不足的事实也表明脚本确实成功地在目标目录上创建了文件，这意味着目标目录确实存在。 （Windows 不会凭空发明共享名称，因此如果脚本错误地使用“xxx`$”作为共享名称（如您所假设），就不会发生这种情况。）
确保 UNC 路径实际上代表您期望的服务器端文件夹（即，可能只是您正在查看文件夹 A，但共享已映射到文件夹 B）。如果您知道文件名，请在服务器的所有磁盘中搜索该确切名称（例如 Cmd 的dir/a/b/s c:\foo.log）。如果磁盘已满，请运行 SpaceSniffer 或 WinDirStat 并查看最大的目录是什么 - 那就是您的日志所在的位置。