运行 Windows 7,当我复制文件在例程期间到外部磁盘文件备份,我使用 Powershell v2(从批处理文件)在副本文件上重新创建原始文件的所有时间戳。
以下代码在大多数情况下都能成功运行,但并非总是如此:-
SET file=%1
SET dest=E:\
COPY /V /Y %file% "%dest%"
SetLocal EnableDelayedExpansion
FOR /F "usebackq delims==" %%A IN ('%file%') DO (
SET fpath=%%~dpA
SET fname=%%~nxA
)
PowerShell.exe (Get-Item \"%dest%\%fname%\").CreationTime=$(Get-Item \"%fpath%%fname%\" ^| Select-Object -ExpandProperty CreationTime ^| Get-Date -f \"MM-dd-yyyy HH:mm:ss\")
上面的代码复制文件,然后当我将源文件拖放到批处理文件上时,将副本(目标)文件的创建日期/时间设置为源文件的创建日期/时间。
但在某些情况下,代码会失败。如果文件名包含“毒药”字符,例如(例如)方括号[...],它给出了错误“在此对象上找不到属性“CreationTime”“。文件名的解析显然在“有毒”字符处失败。
代码确实not给出错误的符号,例如&.
我尝试了使用单引号和双引号转义 Powershell 命令的各种变体,但没有成功。请有人告诉我如何转义 Powershell 反对的那些字符。
这只是一个更长的批处理例程的一小部分,我依靠它来进行定期系统备份。我没有切换到 .ps1 文件的选项,因此我需要一个在批处理文件中而不是在 .ps1 文件中工作的解决方案。
感谢您的所有建议。
ADDENDUM:我找到了一个解决方案,采纳了 mklement0 善意提供的一项建议。通过用以下命令替换我原来的 Powershell 命令,解决了我的方括号问题 -
PowerShell.exe (Get-Item -LiteralPath \"%dest%\%fname%\").CreationTime=$(Get-Item -LiteralPath \"%fpath%%fname%\" ^| Select-Object -ExpandProperty CreationTime ^| Get-Date -f \"MM-dd-yyyy HH:mm:ss\")
为了便于将来参考,请注意(关于Windows 7的):
-
使用此修改后的命令可以成功保留任何额外的空白字符。这是not需要包含一对额外的双引号字符才能实现此目的。
- Editor's note: It's an edge case, but worth pointing out: without extra enclosing double quotes, any runs of more than one space are folded into one space; e.g.,
powershell.exe -command echo \"a b\"
yields a b
.
Enclosing the entire command in "..."
helps in principle -
powershell.exe -command "echo \"a b\""
- but since cmd.exe
then doesn't recognize the overall string as a single, double-quoted string, metacharacters can break the command; e.g.,
powershell.exe -command "echo \"a & b\""
It is not文件路径可能包含任何“(双引号)字符,因此不需要任何代码来转义该字符。双引号字符在 FAT 和 NTFS 文件系统中是非法字符,因此永远不会在文件路径中遇到。
原则上在 Powershell 命令中使用 ' (单引号)是不好的,因为该字符在 NTFS 文件系统中不是非法的,因此可以在文件的实际路径中找到。必须优先使用双引号,因为双引号字符是非法的,在实际的 NTFS 路径中永远不会遇到。
-
使用 ROBOCOPY,以下通配符解决方案成功even与大多数有毒角色 - 除!(即它可以应对=&`^)。即使有,这个命令也非常强大more超过一个有毒字符(尽管并非万无一失):
ROBOCOPY "%fpath% " "%dest%" "*%name%*%ext%*" /B /COPY:DAT /XJ /SL /R:0 /W:0 /V
A。 “%fpath%”中的空格是必需的,它不是错误。
b.在所有情况下唯一致命的有毒字符是感叹号 (!)。
C。有毒字符似乎只是文件名中的问题,而不是路径中的问题。