我希望一双更有经验的眼睛能发现我明显缺少的东西，或者能够帮助我解决mv和rsync产生的错误。准备好迎接挑战了吗？
基本思想：
我有一个bash脚本，在该脚本中我可以自动将文件从一个目录移动到另一个目录。
问题：
运行脚本时，会定期从mv命令中收到以下错误：mv: cannot stat `/shares/directory with spaces/test file.txt': No such file or directory。vm命令的错误代码为1。更奇怪的是，文件移动有时确实会成功。
此外，我在脚本中有一个逻辑分支，它将交替使用rsync来移动/复制特定文件(来自与上述mv命令相同的本地文件系统源和目标)。我得到了一个与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]
运行脚本时，此错误并不总是显示出来。有时它会毫无怨言地完成文件移动，而另一些时候，当脚本连续运行时，它会一致地返回错误。
还有一个额外的因素你应该知道(我越来越怀疑这是我悲伤的一个关键因素)：目录/shares/是一个由Dropbox安装监控的目录，这意味着它由Dropbox的安装监控和镜像。在这一点上，我无法确定dropboxd是否以某种方式锁定了文件等，从而使其无法进行统计。需要明确的是，这些文件最终会在没有进一步干预的情况下从这种状态中释放出来，并且可以使用mv。
代码：
mv -v --no-clobber "${SOURCEPATH}${item}" "${DESTINATIONPATH}${item}"
更多信息：
以下内容可能相关，也可能不相关：
mount表示文件系统是ext4- 据推测，所有权和权限不应该成为的问题，因为脚本是由root运行的。尤其是如果文件系统不是基于fuse的
- 路径中的基本"目录"(例如/shares/)是指向同一文件系统上另一个目录的符号链接
- Linux的风格是Debian
故障排除：
在试图消除变量扩展或其内容的任何问题时，我在通过ls -al验证"测试文件.txt"存在后，尝试硬连接bash脚本，如下所示：mv -v --no-clobber "/shares/directory with spaces/test file.txt" "/new destination/directory with spaces/test file.txt"。作为参考，权限为：-rw-r-r-
不幸的是，这也会导致同样的错误。
我能想到的其他可能的问题，以及我已经做了什么来试图排除它们：
>>可能的问题：硬盘速度慢(或驱动器处于低功耗模式)或外部USB驱动器
>发现：驱动器都是本地SATA磁盘，设置为非驻车磁头。此外，即使在强制从文件系统进行一致读取时，也会发生相同的错误
>可能的问题：非Linux、NFS或基于fuse的文件系统
>发现：nope，源和目标位于同一本地文件系统上，mount表示文件系统为ext4
>>可能的问题：文件路径中有空格或其他不可打印的字符
>发现：验证了源和目标路径是否正确地用引号包裹
>>可能的问题：转义换行后的继续问题(换行命令中\后的空格)
>发现：>确保命令都在一行上，仍然是相同的错误
>>可能的问题：globbing(在指定要移动的文件时使用*)
>发现：nope，每个文件都直接由路径和名称指定
>>可能的问题：使用本地路径造成的路径混淆
>发现：nope，文件路径从/开始完全限定
>>可能的问题：文件实际上不在指定的路径中
>>发现：nope，在通过ls -al执行脚本之前验证文件存在
>>可能的问题：不知何故，mv的--no clobber导致了问题
>发现：noe，尝试过，没有，相同的错误
>可能的问题：只有通过Dropbox同步到文件系统创建的文件有问题
>发现：nope，直接通过touch new-local-file.txt创建了一个本地文件，它也产生了相同的stat()错误
我的分析：
mv和rsync产生类似的stat()错误这一事实让我相信：
- 有一些系统性的底层边界情况(例如文件权限/所有权或文件繁忙)在bash脚本中没有考虑；或
- 在CCD_ 20和CCD_
期望结果：
1。可以确定间歇性错误的根本原因
2。根本原因可以解决或解决
3。bash脚本可以进行改进，以便在错误发生时进行优雅的处理。
因此，通过更多的故障排除，我在脚本的大约200行之前发现了一个错误的rsync语句，该语句是有条件执行的(因此看起来不一致的行为)。rsync --archive ...语句被传递给/shares/作为其源目录，因此它影响了/shares/directory with spaces/子目录。该子目录是我在上面的文章中提到的令人不安的mv命令的${SOURCEPATH}。
最终，是rsync --archive ...语句中缺少--dry-run标志，导致了脚本后来期望传递给mv进行处理的文件被践踏。
感谢所有花时间阅读我帖子的人。虽然我很沮丧花了我和你的时间在我的脚本中发现了一个错误，但我很欣慰地知道：
-计算机不是不合理的
--我没有疯
-linux文件系统中没有一些邪恶的、根深蒂固的错误
对于那些将来因为遇到cannot stat错误而偶然发现这篇文章的人，请阅读我上面的故障排除说明。很多研究都进入了这个列表。其中之一可能是你的问题。如果没有，继续调试，有一个解释。祝你好运