![停止(Ctrl+Z)通过网络复制应用程序](https://linux22.com/image/1321878/%E5%81%9C%E6%AD%A2%EF%BC%88Ctrl%2BZ%EF%BC%89%E9%80%9A%E8%BF%87%E7%BD%91%E7%BB%9C%E5%A4%8D%E5%88%B6%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F.png)
我有许多 bash 脚本,它们使用cp
CIFS(Windows)挂载通过网络复制文件。
- 使用 Ctrl+Z 中断脚本(然后当然使用 再次恢复
[fg,bg] <job ID>
)是否存在导致数据损坏或任何其他异常的风险? - 此外,风险是否取决于您复制的支架类型?
这些问题假设网络连接在任何时候都不会物理中断或丢失,即通过“拔掉插头”或强行卸载。
答案1
当您使用 Ctrl-Z 停止某个进程时,除非它明确监视信号,否则它并“不知道”该进程已暂停。
换句话说,另一端的数据被破坏的风险很小甚至没有。
我说“很少或没有”是因为如果作业暂停时间过长,通信路径总是存在某种超时风险。例如,许多 NAT 实现中都隐含了超时,因此如果路径中有 NAT 路由器,那么长时间暂停可能会出现问题。我真的不能说“太长”是多长时间,但如果你只是在几秒钟内中断作业并将其置于后台,我会说这种超时风险几乎为零。
我认为源文件或目标文件类型在这里并不重要;同样,某些源文件和目标文件可能不喜欢暂停。我在这里没有考虑有缺陷的实现;有缺陷的内核可能不喜欢进程被停止,但我从未在实践中见过这种情况。
在您的情况下,一个明智的举措可能是使用 rsync;结合 Ctrl-Z,您可以获得非常好的控制度 - 既可以停止,又可以重新启动失败的传输(需要明确的是,我假设失败的原因不是进程停止)。
这里有一个重点 - 如果您在交互式多命令行中停止作业,有时下一个作业会启动,或者恢复时会忘记其他作业。您可以使用类似以下命令进行测试:echo 1; sleep 10; echo 2; echo 3,并在睡眠期间停止作业,看看是否在正确的时间以正确的顺序打印了所有数字。这不适用于 shell 脚本;Ctrl-Zed shell 脚本将从您停止的位置恢复。