Fatal编程技术网
  • linux/
  • Linux mv命令移动文件但报告错误：无法统计没有这样的文件或目录

Linux mv命令移动文件但报告错误：无法统计没有这样的文件或目录

linux bash

Linux mv命令移动文件但报告错误：无法统计没有这样的文件或目录,linux,bash,rsync,stat,mv,Linux,Bash,Rsync,Stat,Mv,我希望更有经验的人会发现我明显缺少的东西，或者能够帮助我解决mv和rsync产生的错误。准备好迎接挑战了吗 基本理念： 我有一个bash脚本，在这个脚本中，我自动地将文件从一个目录移动到另一个目录 问题： 当我运行脚本时，定期从mv命令中得到以下错误： mv:cannotstat`/shares/directory with spaces/test file.txt'：没有这样的文件或目录。vm命令的错误代码为1。更奇怪的是，文件移动有时会成功 此外，我在脚本中有一个逻辑分支，它将交替使用rsy

我希望更有经验的人会发现我明显缺少的东西，或者能够帮助我解决
mv
和
rsync
产生的错误。准备好迎接挑战了吗

基本理念：
我有一个bash脚本，在这个脚本中，我自动地将文件从一个目录移动到另一个目录

问题：
当我运行脚本时，定期从
mv
命令中得到以下错误：
mv:cannotstat`/shares/directory with spaces/test file.txt'：没有这样的文件或目录
。
vm
命令的错误代码为1。更奇怪的是，文件移动有时会成功

此外，我在脚本中有一个逻辑分支，它将交替使用
rsync
来移动/复制特定文件（与上面提到的
mv
命令来自相同的本地文件系统源和目标）。我得到一个与stat（）系统调用相关的类似错误：
rsync:link_stat“/shares/directory with spaces/test file.txt”失败：没有这样的文件或目录（2）
rsync错误：main.c（1070）[sender=3.0.9]

当脚本运行时，此错误并不总是表现出来。有时，它会毫无怨言地完成文件移动，而有时，当脚本连续运行多次时，它会一致地返回错误

还有一个你应该注意的因素（我越来越怀疑这是我悲伤的一个关键因素）：目录/shares/是一个目录，它被Dropbox的安装监视着——这意味着它被Dropbox的安装监视和镜像着。此时，我无法确定是否
dropboxd
以某种方式锁定了文件或类似文件，从而无法对其进行统计。要明确的是，文件最终会在无需进一步干预的情况下从该状态中释放出来，并且可以
mv

代码：
mv-v--no-clobber“${SOURCEPATH}${item}”${DESTINATIONPATH}${item}”

更多信息：
以下内容可能相关，也可能不相关：

  • mount
    表示文件系统是ext4
  • 据推测，所有权和权限不应该是问题，因为脚本是由root用户运行的。尤其是如果文件系统不是基于fuse的
  • 路径（例如/shares/）中的基本“目录”是指向同一文件系统上另一个目录的符号链接
  • Linux的风格是Debian
故障排除：
为了消除变量扩展或其内容的任何问题，我尝试像这样硬连接bash脚本：
mv-v--no clobber”/通过
ls-al
验证“test file.txt”是否存在后，使用空格/test file.txt”“共享/目录/new destination/directory/spaces/test file.txt”“
。作为参考，权限为：-rw-r--r--
不幸的是，这也会导致同样的错误

我可能想到的其他问题，以及我为排除这些问题所做的努力：

>>可能的问题：硬盘速度慢（或驱动器处于低功耗模式）或外部USB驱动器
>>发现：驱动器均为本地SATA磁盘，设置为非驻车磁头。此外，即使强制从文件系统进行一致读取，也会发生相同的错误

>>可能的问题：非Linux、NFS或基于fuse的文件系统
>>发现：不，源和目标在同一个本地文件系统上，
mount
表示文件系统是ext4

>>可能的问题：文件路径中存在空白或其他无法打印的字符
>>发现：验证源路径和目标路径是否正确地用引号括起来

>>可能的问题：转义换行符后的延续问题（wrapped命令中\后的空格）
>>发现：确保命令都在一行上，仍然是相同的错误

>>可能的问题：globbing（使用*指定要移动的文件）
>>发现：不，每个文件都直接由路径和名称指定

>>可能的问题：使用本地路径导致路径混淆
>>发现：不，文件路径从/

>>可能的问题：文件实际上不在指定的路径中
>>发现：没有，在通过
ls-al执行脚本之前，验证了文件存在

>>可能的问题：不知何故，mv的--no撞击导致了问题

>>调查结果：没有，试过没有，同样的错误

>>可能的问题：只有通过Dropbox同步到文件系统创建的文件有问题

>>发现：不，直接通过
touch new local file.txt
创建了一个本地文件，它也产生了相同的stat（）错误

我的分析：


mv
和
rsync
产生类似stat（）错误的事实让我相信：


    

  • bash脚本中没有考虑某些系统性的底层边界情况（例如文件权限/所有权或文件繁忙）；或
    • 

  • 同样的错误在
    mv
    和
    rsync
    场景中困扰着我


期望的结果：

1.可以确定间歇性错误的根本原因。

2.根本原因可以解决或解决。


3.可以改进bash脚本，以便在发生错误时能够优雅地处理
 因此，通过更多的故障排除，我在脚本前面约200行有条件执行的
rsync
语句中发现了一个错误的语句（因此看起来不一致的行为）。该
rsync--archive…
语句被传递为其源目录
/shares/
，因此它影响了带有s的
/shares/目录