今天又是一个一个一个一个野兽节啊啊啊啊啊🤔处理某个度盘小号的时候，一不小心cd错了目录，或者说cd压根就没有执行，然后我来了一句rm *，好家伙，整个盘的东西全没了（全恼🤔

所以我只能将它们全部恢复出来，并花了11451.4秒重新修改它们的时间戳🤔其实度盘这玩意有两个时间戳，创建时间是不变的，修改时间这玩意可以任意变🤔按理来说完全就没有任何修改度盘文件的方法，但它居然就是有这么一个时间戳，比如目录重命名和里面的东西有改变（比如删了一个文件或者保存了一个文件，或者重命名一个文件），就会变化🤔而如果给一个目录重命名或者将它从回收站里恢复出来的话，里面所有东西（包括子目录，和里面的文件）的修改时间都会便乘目录被重命名或者恢复时的时间（严格点来说有一个一两秒的延时🤔

更离谱的是，之前设置的onedrive转三盘，8个线程里7个都跑完了，只有第一个线程卡在那里，只处理了四五个文件，而且也没有输出日志，直接就卡超时了（恼🤔

那我只能将这一整个线程里的链接分成8个线程重新搞一遍🤔最后统计下来，onedrive和guilded都完成上传了，度盘那边居然有五个文件是0字节，一看日志，草，这些文件在最后合并分片的时候发生了连接超时，而它居然没有重试的能力，wiebitte？🤔

也许我可以直接从本地上传这五个文件，但在此之前我更愿意再跑一遍之前写的onedrive转度盘脚本重新上传它们，毕竟github actions还是快很多（确信🤔

除此之外，我在onedrive上传三盘或度盘的脚本里还加了一句sumfile，就和我本地处理这些文件时的sumfile一毛一样，它至少可以算个md5出来，这样通过对比日志文件和我本地的sumfile文件，我至少可以知道从onedrive上下载下来的文件是不是我本地曾经存在的文件（确信🤔况且sumfile除了文件md5外，还能算出文件前256KB部分的md5，反正我寻思由于文件下载过程中出现故障导致这两个md5都能保持不变的概率低到可以忽略不计，所以基本上sumfile能对上，就说明onedrive下载下来的文件等于我本地的文件（确信🤔

thonk

纯度盘上传脚本就没出什么岔子，全部上传完了🤔对比它和三盘脚本，它们度盘部分唯一的区别，居然是旧脚本设置了32线程，而新脚本设置了40线程，就这个🤔

但这次跑脚本时onedrive至少一点事都没出，一次下载错误都没有，剩下两个drive也没出问题（确信🤔那么下次跑脚本时也不用多说，度盘上传线程调小就vans了，先调到32，还是不行就降到24🤔