这几天bash脚本批处理化（迫真）的antics还在继续，guilded上传脚本也被我魔改好了🤔

但它现在至少存在两个问题：

• 上传速度实在是太慢了，哪怕梯子加速后还是⑧行🤔毕竟这玩意是流式上传的，所以至少目前，它只能搞成单线程，我这边加上梯子最高也只有3MB/s，反正比discord drive差远了（悲🤔

• 由于路径转换的问题，尤其是涉及到win到linux的转换，输进tar命令的路径都便乘了绝对路径🤔但tar的话，在我知道如何进一步设置前，如果输进去了绝对路径，它会把这一大坨路径除去根目录的/都保存起来的，到时候解压的时候也全部解压出来🤔而我更想达到的效果是只保存那个目录本身🤔到此解决方案是要么看tar有没有啥设置搞这个，要么cd到这个绝对路径的上一层目录，然后在那里tar那个目录，这样tar记录下来的目录结构就是我要的了（确信🤔

但这么搞可能会产生新的问题，tar之后split还需要在一个subshell里执行上传的脚本，那个脚本的当前目录会便乘什么？🤔如果它会便乘比如我们要处理的目录相关的玩意的话，那么上一个脚本里的当前目录这个参数，我们是不是要给它传进去？🤔

thonk

另外，我觉得用guilded drive来大规模保存之前下的将近1TB的种子，可能是一个好主意🤔因为种子自然是一个种子下载出一个目录（有时候种子下载出来的只有一个文件，但我在的pt强制要求一个种子必须建立一个目录），而guilded流式上传脚本刚好可以将一个目录便乘一个guilded drive链接，所以一个种子就便乘了一个链接，到时候下载时也是一个链接便乘了一个种子对应的目录，完美🤔

而discord drive就没那么方便了，对于旧discord drive来说，我还得对每一个目录手动rar，手动验checksum，还要手动上传，尽管我当时处理u2的时候的确写了一个半自动化玩意，但它还是麻烦🤔单文件discord drive？它只能拆分单文件，我是不是还得将一个种子对应的目录手动压缩成单个rar文件？（恼🤔

而guilded drive就没那么多麻烦，直接对着一个目录写一个for循环，将每一个子目录塞进脚本撸就vans了（确信🤔

现在已经搞了好几个小时了，平均下来20MB/s，一分钟1.2GB，基本上和旧discord drive的1GB到1.5GB一分钟持平了（确信🤔当然，旧discord drive可是有验证每个包checksum的功能的，不然50MB/s都能随便上🤔

至于guilded drive生成的链接没有任何信息这一点，，，其实我每次处理前将ls出来的目录列表贴在discord频道里就vans了，由于for循环肯定是顺序执行的，贴出来的目录顺序肯定和生成的guilded drive链接顺序是完全一样的，到时候按照顺序找某个资源对应的链接就vans了（确信🤔

fischlthonk

guilded drive流式目录上传还有没有优化的空间？比如，流式上传也实现多线程？🤔

首先，guilded drive能实现流式上传，是因为tar打包后的数据流被塞进了split里，它被设置成每到它接收的数据流达到了一定大小（比如200MB-114514字节），它就会在subshell里调用另外一个脚本，将这些数据流塞进这个脚本里上传🤔

那么，如果想要上传这个功能便乘多线程的话，它首先需要实现一个计数器，使得每一个subshell里跑的上传脚本都知道这段要上传的数据流属于全部数据流的第几个part🤔然后，这些subshell需要能并行跑起来，而非像现在这样每tar到某个大小后会阻塞到上传脚本完成上传为止🤔

当然，也许它存在一个相对比较简单的方法，以4线程为例，将800MB数据流传给subshell，而subshell里的上传脚本会将其保存到某个临时文件夹或者tmpfs里，再将保存的文件用单文件discord drive同款方法（tail | head）四线程上传就vans了，只要确保这四个文件上传后的链接顺序是对的（比如第一个分片文件上传后的链接在四行里的第一行），甚至都不用记录它是总数据流的第几个part🤔

这样，主脚本基本上不需要改，最多加几个参数（确信🤔

AYAYA

在又一个1145.14秒后，目录打包guilded drive终于便乘了多线程上传版本🤔subshell脚本被我扩写了一番，考虑到subshell脚本通常是主脚本生成的，它发生了一系列生草的事情🤔比如上次我也许说过的，在那里面写的变量在写入subshell脚本前会进行一番变量替换🤔但更生草的是里面写的命令替换部分（用来将上传结果赋予一个变量，因为我需要将那个返回的链接和partno一块输出）也会先执行一遍命令替换再写入subshell脚本，实在是草🤔所以最后我只能将\$和```全部给转义了，现在subshell脚本终于恢复了正常（确信🤔

接下来多线程部分也极其生草，一般来说在for循环里面写一个花括号然后里面写入要多线程执行的命令，后面再加一个&，它们在for循环执行完后会全部后台执行，而主脚本也会继续执行，除非done后面加一行wait🤔但如果我在done后面跟一个管道的话，它会等这些线程执行完，然后将它们的输出结果汇总起来，再扔进管道里🤔有点意思🤔

所以，我在for循环的内层，先让一个初始值为0的计数器（表示partno）加1，然后将partno的值连同临时文件的offset（也就是从第几个字节开始上传🤔至于上传多少字节？这部分由主脚本的变量决定，就像我之前说的，生成subshell脚本的过程中会搞变量替换，这样它就会写进subshell脚本里面）传进上传函数里面🤔而上传函数并不会像之前那样直接打印出上传后guilded返回的链接，它需要先保存这个链接，然后将其和之前那个计数器变量以partno|link的形式合并输出🤔

输出之后我在for循环的末尾加上管道，来一个sort -n，实测哪怕它是上面那种格式，也能在线程数超过⑨的情况下正确输出从1到最后一个线程的链接🤔那么，再用cut提取出链接，写入到某个文件，这个多线程脚本就搞完了（确信🤔

以相同的思路，我们也可以往discord drive里流式上传目录，此时每一个线程对应一个webhook url🤔只不过每次二三十个线程同时开火，怎么看都不像是什么高效的上传方法就是了（恼🤔

现在，压力来到了cygwin最小环境这边（确信🤔

JAJAJAJAJA

在又一番瞎鸡巴折腾后，cygwin最小环境里也可以使用多线程guilded drive了🤔https://s3-us-west-2.amazonaws.com/www.guilded.gg/ContentMediaGenericFiles/5f8b4d775b5bc0eadb7deb0e17f41d81-Full.zip
，请（吴慈悲🤔

上传速度还行，至少比我之前撸的单线程guilded drive快多了，哪怕用upload.barbruh.lol这个完全没有梯子加速的上传api，也能达到最高⑨0Mbps（确信🤔不错，这事终于告一段落了（迫真🤔