mv command moves file but reports error: cannot stat no such file or directory
mv command moves file but reports error: cannot stat no such file or directory
我希望更有经验的人会发现我遗漏的一些明显的东西，或者能够帮助我解决 mv 和 rsync 产生的错误。准备好迎接挑战了吗？
基本思路：
我有一个 bash 脚本，我在其中自动将文件从一个目录移动到另一个目录。
问题：
当我 运行 脚本时，我会定期从 mv 命令中收到以下错误：
mv: cannot stat `/shares/directory with spaces/test file.txt': No such file or directory。 vm 命令的错误代码是 1。更奇怪的是，有时文件移动实际上会成功。
此外，我在脚本中有一个逻辑分支，它将交替使用 rsync 到 move/copy 特定文件（来自与 [=10= 相同的本地文件系统源和目标） ] 上面提到的命令）。我收到与 stat() 系统调用相关的类似错误：
rsync: link_stat "/shares/directory with spaces/test file.txt" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]
当脚本为 运行 时，此错误并不总是出现。有时它会毫无怨言地完成文件移动，而有时它会 return 当脚本连续 运行 次时，它会始终如一地出现错误。
您还应该注意一个额外的因素（我越来越怀疑这是我悲伤的一个关键因素）：目录 /shares/ 是一个由安装的 Dropbox 监控的目录 - - 表示它由安装的 Dropbox 监视和镜像。在这一点上，我无法确定 dropboxd 是否以某种方式锁定了文件，或者类似的，以至于它不能被统计。需要明确的是，这些文件最终会在没有进一步干预的情况下摆脱这种状态，并且可以 mv-able。
代码：
mv -v --no-clobber "${SOURCEPATH}${item}" "${DESTINATIONPATH}${item}"
更多信息：
以下内容可能相关，也可能不相关：
mount表示文件系统为ext4- 据推测，所有权和权限 不应该 成为问题，因为脚本由 root 运行 执行。特别是如果文件系统不是基于融合的。
- 路径中的基础 "directory"（例如 /shares/）是指向同一文件系统上另一个目录的符号链接。
- Linux 的风格是 Debian。
疑难解答：
为了消除变量扩展或其内容的任何问题，我尝试像这样硬连接 bash 脚本：
mv -v --no-clobber "/shares/directory with spaces/test file.txt" "/new destination/directory with spaces/test file.txt" 在通过 ls -al 验证 "test file.txt" 存在之后。作为参考，权限为：-rw-r--r--
不幸的是，这也会导致同样的错误。
我能想到的其他可能的问题以及我为排除这些问题所做的工作：
>> 可能的问题： 慢速 HDD（或驱动器处于低功耗模式）或外部 USB 驱动器
>> 调查结果： 驱动器都是本地 SATA 磁盘，设置为不放置磁头。另外，即使强制从文件系统进行一致读取，也会出现同样的错误
>> 可能的问题： 非 Linux、NFS 或基于 fuse 的文件系统
>> 调查结果： 不，源和目标在同一本地文件系统上并且 mount 表示文件系统是 ext4
>> 可能的问题： 白色 space 或文件路径中的其他不可打印字符
>> 调查结果： 验证源路径和目标路径正确地用引号括起来
>> 可能的问题： 换行符转义后的继续问题（space 在包装命令中的 \ 之后）
>> 调查结果： 确保命令全部在一行中，仍然是相同的错误
>> 可能的问题： 通配符（使用 * 指定要移动的文件）
>> 调查结果： 不，每个文件都直接由路径和名称指定
>> 可能的问题： 使用本地路径造成路径混乱
>> 结果： 不，文件路径从 /
开始是完全合格的
>> 可能的问题： 文件实际上不在指定的路径中
>> 结果： 不，通过 ls -al
验证文件在执行脚本之前就存在
>> 可能的问题： mv 的 --no-clobber 以某种方式导致了问题
>> 调查结果： 不，没有试过，同样的错误
>> 可能的问题： 只有通过 Dropbox 同步到文件系统创建的文件有问题
>> 结果： 不，直接通过 touch new-local-file.txt 创建了一个本地文件，它也产生了相同的 stat() 错误
我的分析：
mv 和 rsync 产生类似的 stat() 错误这一事实让我相信：
- bash 脚本中没有考虑到一些系统性的潜在边界情况（例如文件 permissions/ownership 或文件繁忙）；或者
- 同样的错误在
mv 和 rsync 场景中困扰着我。
期望的结果：
1. 可以确定间歇性错误的根本原因。
2. 根本原因可以解决或解决。
3. 改进bash脚本，在出现错误时可以优雅地处理。
因此，通过更多的故障排除，我在有条件地执行的脚本中发现了大约 200 行前面的错误 rsync 语句（因此看似不一致的行为）。该 rsync --archive ... 语句作为其源目录被传递 /shares/，因此它影响了 /shares/directory with spaces/ 子目录。该子目录是我上面 post 中提到的令人不安的 mv 命令的 ${SOURCEPATH}。
最终，rsync --archive ... 语句中缺少 --dry-run 标志，导致脚本稍后希望传递给 mv 进行处理的文件遭到破坏。
感谢所有花时间阅读我的 post 的人。虽然我和你的时间都花在了我的脚本中的错误上，但我很遗憾，但令人欣慰的是：
- 电脑不是非理性的
- 我没疯
- linux 文件系统
中没有一些邪恶的、根深蒂固的错误
对于那些将来因遇到 cannot stat 错误而偶然发现此 post 的用户，请阅读我上面的故障排除说明。很多研究都进入了那个列表。其中之一可能是您的问题。如果没有，继续调试，有解释。祝你好运！
我希望更有经验的人会发现我遗漏的一些明显的东西，或者能够帮助我解决 mv 和 rsync 产生的错误。准备好迎接挑战了吗？
基本思路：
我有一个 bash 脚本，我在其中自动将文件从一个目录移动到另一个目录。
问题：
当我 运行 脚本时，我会定期从 mv 命令中收到以下错误：
mv: cannot stat `/shares/directory with spaces/test file.txt': No such file or directory。 vm 命令的错误代码是 1。更奇怪的是，有时文件移动实际上会成功。
此外，我在脚本中有一个逻辑分支，它将交替使用 rsync 到 move/copy 特定文件（来自与 [=10= 相同的本地文件系统源和目标） ] 上面提到的命令）。我收到与 stat() 系统调用相关的类似错误：
rsync: link_stat "/shares/directory with spaces/test file.txt" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]
当脚本为 运行 时，此错误并不总是出现。有时它会毫无怨言地完成文件移动，而有时它会 return 当脚本连续 运行 次时，它会始终如一地出现错误。
您还应该注意一个额外的因素（我越来越怀疑这是我悲伤的一个关键因素）：目录 /shares/ 是一个由安装的 Dropbox 监控的目录 - - 表示它由安装的 Dropbox 监视和镜像。在这一点上，我无法确定 dropboxd 是否以某种方式锁定了文件，或者类似的，以至于它不能被统计。需要明确的是，这些文件最终会在没有进一步干预的情况下摆脱这种状态，并且可以 mv-able。
代码：
mv -v --no-clobber "${SOURCEPATH}${item}" "${DESTINATIONPATH}${item}"
更多信息：
以下内容可能相关，也可能不相关：
mount表示文件系统为ext4- 据推测，所有权和权限 不应该 成为问题，因为脚本由 root 运行 执行。特别是如果文件系统不是基于融合的。
- 路径中的基础 "directory"（例如 /shares/）是指向同一文件系统上另一个目录的符号链接。
- Linux 的风格是 Debian。
疑难解答：
为了消除变量扩展或其内容的任何问题，我尝试像这样硬连接 bash 脚本：
mv -v --no-clobber "/shares/directory with spaces/test file.txt" "/new destination/directory with spaces/test file.txt" 在通过 ls -al 验证 "test file.txt" 存在之后。作为参考，权限为：-rw-r--r--
不幸的是，这也会导致同样的错误。
我能想到的其他可能的问题以及我为排除这些问题所做的工作：
>> 可能的问题： 慢速 HDD（或驱动器处于低功耗模式）或外部 USB 驱动器
>> 调查结果： 驱动器都是本地 SATA 磁盘，设置为不放置磁头。另外，即使强制从文件系统进行一致读取，也会出现同样的错误
>> 可能的问题： 非 Linux、NFS 或基于 fuse 的文件系统
>> 调查结果： 不，源和目标在同一本地文件系统上并且 mount 表示文件系统是 ext4
>> 可能的问题： 白色 space 或文件路径中的其他不可打印字符
>> 调查结果： 验证源路径和目标路径正确地用引号括起来
>> 可能的问题： 换行符转义后的继续问题（space 在包装命令中的 \ 之后）
>> 调查结果： 确保命令全部在一行中，仍然是相同的错误
>> 可能的问题： 通配符（使用 * 指定要移动的文件）
>> 调查结果： 不，每个文件都直接由路径和名称指定
>> 可能的问题： 使用本地路径造成路径混乱
>> 结果： 不，文件路径从 /
>> 可能的问题： 文件实际上不在指定的路径中
>> 结果： 不，通过 ls -al
>> 可能的问题： mv 的 --no-clobber 以某种方式导致了问题
>> 调查结果： 不，没有试过，同样的错误
>> 可能的问题： 只有通过 Dropbox 同步到文件系统创建的文件有问题
>> 结果： 不，直接通过 touch new-local-file.txt 创建了一个本地文件，它也产生了相同的 stat() 错误
我的分析：
mv 和 rsync 产生类似的 stat() 错误这一事实让我相信：
- bash 脚本中没有考虑到一些系统性的潜在边界情况（例如文件 permissions/ownership 或文件繁忙）；或者
- 同样的错误在
mv和rsync场景中困扰着我。
期望的结果：
1. 可以确定间歇性错误的根本原因。
2. 根本原因可以解决或解决。
3. 改进bash脚本，在出现错误时可以优雅地处理。
因此，通过更多的故障排除，我在有条件地执行的脚本中发现了大约 200 行前面的错误 rsync 语句（因此看似不一致的行为）。该 rsync --archive ... 语句作为其源目录被传递 /shares/，因此它影响了 /shares/directory with spaces/ 子目录。该子目录是我上面 post 中提到的令人不安的 mv 命令的 ${SOURCEPATH}。
最终，rsync --archive ... 语句中缺少 --dry-run 标志，导致脚本稍后希望传递给 mv 进行处理的文件遭到破坏。
感谢所有花时间阅读我的 post 的人。虽然我和你的时间都花在了我的脚本中的错误上，但我很遗憾，但令人欣慰的是：
- 电脑不是非理性的
- 我没疯
- linux 文件系统
对于那些将来因遇到 cannot stat 错误而偶然发现此 post 的用户，请阅读我上面的故障排除说明。很多研究都进入了那个列表。其中之一可能是您的问题。如果没有，继续调试，有解释。祝你好运！