Closed starrin closed 1 month ago
我想了一下,可以把 Core 和资源安装在一个临时的目录,在确保安装完成之后,把原本的文件移动到里临时位置并把安装新的文件移到目标目录,最后再自信删除操作,确保不会安装或者删除失败导致 Core 直接没有了。不过我不确定把这个临时的文件夹在哪里比较合适,如果临时目录和目标目录不在同一个文件系统里会导致性能问题,同时跨文件系统移动可能也会导致删除失败问题。当然,最好的方法是避免把原本的目录清空,而是通过类似 https://github.com/MaaAssistantArknights/MaaRelease/issues/146 方式来进行增量更新,避免进行清空文件夹操作,毕竟资源文件真的很多。但是目前就多尝试几次来解决这个问题吧。
我想了一下,可以把 Core 和资源安装在一个临时的目录,在确保安装完成之后,把原本的文件移动到里临时位置并把安装新的文件移到目标目录,最后再自信删除操作,确保不会安装或者删除失败导致 Core 直接没有了。不过我不确定把这个临时的文件夹在哪里比较合适,如果临时目录和目标目录不在同一个文件系统里会导致性能问题,同时跨文件系统移动可能也会导致删除失败问题。当然,最好的方法是避免把原本的目录清空,而是通过类似 MaaAssistantArknights/MaaRelease#146 方式来进行增量更新,避免进行清空文件夹操作,毕竟资源文件真的很多。但是目前就多尝试几次来解决这个问题吧。
方不方便在重试之前加个短一点的延时?0.1s或者0.2s左右的应该就可以,感觉这样基本上就能规避nfs文件系统的问题了
由于我用来运行
maa-cli
的云服务器的硬盘空间有限,我把maa-cli
和maa-core
都放到了一个nfs
文件系统中,今天检查服务器日志发现服务器在定时执行maa update
时发生了报错再次尝试执行
maa update
也无法进行(提示MaaCore
无法加载),只能执行maa install
,应该是第一次执行失败时remove_dir_all
实际上已经清空了library
文件夹导致的在网上也能搜索到少量类似反馈,有
rust
的,也有python
库shutil
的,我怀疑是linux中的nfs客户端有缺陷,在递归删除文件夹中的文件时有延迟导致会概率发生这个问题 类似的问题在我这里已经不是第一次出现了,还好这次我及时发现了,不然晚点基建又得崩😭 根据这个问题的表现,感觉maa-cli
在实现ensure_clean
方法时进行一次重试就能规避这个bug,不知道是否方便