到现在guilded drive已经来到了第三代，它第一代就是个单纯的管道玩意，第二代加上了临时文件和多线程上传，第三代加上了检验checksum的功能🤔

那么问题来了：有没有可能在不产生临时文件的情况下实现第二代那样的多线程上传功能？🤔

我今天大致折腾了下，它是可以的，但需要一套相对复杂又相对比第二代简单的方法：

• 首先，和前几代一样，需要将一个每分块大小*线程数这么大的数据流分片用split --filter传送进临时脚本1🤔

• 和第二代不同，在临时脚本1里，接收的数据流并没有暂存到某个文件里，而是接着用split --filter传送进临时脚本2，此时大小被设置为上述的每分块大小🤔

• 而临时脚本2并不是负责上传的脚本，它只不过将数据流照原样传送进临时脚本3，但在之后加了一个&，所以它是临时脚本3实现多线程上传的关键🤔

• 临时脚本3才是真正的上传脚本🤔

和第二代一样，这一代多线程上传脚本也需要在上传完成后标记上传的部分属于哪一个线程🤔但考虑到这么多的split --filter的subshell特性，我最后决定将partno这一玩意用文件的形式传送进临时脚本3：

• 在临时脚本1的开始，将0写入/tmp/counter这个文件🤔

• 然后在临时脚本2的开始，从这个文件里读出值，将其加1，然后再次写入这个文件，再将加了之后的值传送进临时脚本3🤔

• 这样，临时脚本3接收到的partno参数肯定是正确的partno参数，证明过程略（🤔

• 在临时脚本1的split后面加上sort这一坨玩意，将多线程上传的结果进行排序和去除partno🤔

通过这种方式，我们再也不用什么head什么tail来切割临时文件了，整个代码的可读性直接提升了114514倍（迫真🤔

不过我好奇代码写成这样，它还能做流式上传不？比如我现在开了16个线程，每个线程200MB分片，这玩意是要占用3.2GB内存空间，还是不占用？🤔如果curl被我配置成了自动重试，那么当它重试时，是从什么地方读取要上传的内容呢？还是curl会把这部分数据流缓存进它的内存空间？🤔

还有一个问题：既然它现在是流式（迫真）上传了，那么checksum和上传基本上是没什么可能兼得了（恼🤔以前我们可以通过将临时文件读两遍来同时做checksum和上传，现在怎么搞，把管道也拆成两份？等等，stdout这玩意支持塞进两个程序里吗🤔

thonkeqing

另外我之前发现某个片子下载后tar提示数据流有错误，排查发现有一个包完全没有上传上来🤔而且我这次测试脚本的时候也发生了一次这种现象🤔

考虑到我上个月初可是拿这玩意备份了所有的vultr快照，现在好了，我慌的一批（迫真🤔

那么在流式上传过程中，有没有办法像传统读文件上传那样设置重试功能？🤔我的意思是除了在curl里面加重试之外的方法，比如经典检查guilded返回值外层套while法🤔cat -能重复cat很多遍吗？🤔

实测cat -并不能重复很多遍，只有第一遍能接收塞进脚本里的数据流，后面都是空的🤔看来它的确是流式传输啊（确信🤔

这几天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（确信🤔不错，这事终于告一段落了（迫真🤔

这几天度盘一直在抽风，我的两个超会小号都403，我估计就算买一个新的号，它要么给我403，要么更糟糕，解析到一半403（恼🤔

所以，这几天我就不搞了，等我需要搞的最新文件再次积压到不得不搞了再说🤔

所以到今天，我大概把截图基本上全搞定了，照片的话，应该还剩8个小号，也就是大概15TB到16TB的玩意没搞完（悲🤔

guildedthonk

另外guilded drive实在是太寄吧好使了，甚至在我的aria2c完全不上梯子的情况下，它仍然能跑满带宽🤔那真滴牛批，我可能得考虑写一个discord drive转guilded drive的玩意了（确信🤔

另外有没有可能，这玩意在powershell里面跑起来？我就不信它非得装个bash环境才能用🤔假设aria2c.exe和tar.exe已经放进了system32目录，或者不放进去也行，毕竟我们永远可以用guilded drive将这两个可执行文件先下载下来🤔

barbruh

在我一番迫真折腾之后，我发现powershell的管道或者说数据流实现貌似有那么亿点点问题，比如将for循环输出到stdout里的东西要么重定向到文件要么管道到一个不依赖cygwin1.dll的tar实现（貌似叫做bsdtar）里时，它的速度会慢到难以忍受（悲🤔基本上只有十几MB/s，对比cygwin的tar在ramdisk里光速完成解包，可以说是龟速了（全恼🤔

所以，恐怕我只能接着像上次（？）那样，想办法撸一个cygwin最小环境出来了🤔在又一番迫真折腾后，这个powershell（迫真）脚本终于撸出来了，它会先尝试下载一个4MB的zip包，解压后里面是我整的cygwin最小环境，然后它会先将guilded drive的列表文件下到那个cygwin目录里，然后执行里面的bash.exe，参数是sh脚本的位置🤔接下来就非常熟悉了，就是那个原版bash脚本删去wget、rm等powershell自带的函数（确信🤔

但这个脚本它tar解包的速度也慢到难以忍受，经过我一番迫真排除后，最终确定就是那个bsdtar有问题（恼🤔将其替换成cygwin版的tar后（我cygwin1.dll都放进去了，不用白不用），它解包的速度基本上和完整版cygwin一样快了（确信🤔

现在，guilded drive终于普照到了win系统（大嘘🤔下一步是什么？bat？🤔

thonkeqing

又改了一顿脚本，这次将rm.exe也加了进去，所以它现在可以像一代discord drive那样，将guilded drive列表文件拖进bat文件就能自动下载并解压了（确信🤔而且这坨玩意也兼容之前那个powershell版脚本🤔

当然，除了拖文件外，它也可以做一个接受参数是列表文件链接的bat，下载列表文件可以接着用aria2c（确信🤔只不过此时就没法拖什么东西进去了🤔或者我们可以让这个bat来处理一个装满guilded drive列表文件链接的列表文件，此时就可以接着拖了，而且一次性可以处理一大堆（确信🤔

好，到此我已经完成了bash批处理powershell三修（确信🤔

luminethonk

所以我现在懂了，如何将单文件discord drive或者guilded drive的上传脚本普及到win系统？🤔只需要撸一个cygwin最小环境，只带什么curl、aria2c等程序，然后用一个bat作为bash脚本的入口，接下来就可以该怎么用怎么用（大嘘🤔https://s3-us-west-2.amazonaws.com/www.guilded.gg/ContentMediaGenericFiles/fb4b1f769bb8de2d93fc3242c593395f-Full.zip，请（吴慈悲🤔

考虑到本次魔改原脚本花了一大把时间，这还是个只有几行的脚本，这要是去魔改单文件discord drive这种庞然大物的话，我不得寄:barbruh:

thonkcord

最后我还是撸了一个单文件discord drive的cygwin最小系统版🤔前后改了11451.4秒，我也是闲得寄吧蛋疼（🤔

当然，和guilded的上传api一样，我给discord的上传api也整了一波cloudflare antics🤔但discord貌似也用的是cloudflare，而且禁止它的域名被设置成cname🤔所以，我只能用workers来整它的上传antics了（🤔

最后效果还行，不上梯子可以达到平均50Mbps上传🤔

既然上传都搞了，下载要不也来搞一搞🤔当然那个单文件discord drive下载函数已经充满了一系列对下载下来的脚本施加的后处理，而如果它想在这个cygwin最小环境里也跑起来的话，那么它还得再加一层后处理，比如至少把里面用到的那些命令全部改成绝对路径⑧🤔当然，函数本身也得改，反正又一个11451.4秒过去了，现在，它一个压缩包即可以上传discord drive，又可以下载discord drive了，好耶🤔

conclusions

现在来看，它相比原来的脚本，除了将命令的相对路径全部替换成绝对路径外，还是做了亿点点魔改的，比如原来我用file命令来获取文件的mimetype，但那个file.exe移植到cygwin最小环境时，它需要的依赖项多到离谱🤔最后和guilded类似，我上传个连扩展名都没有的文件分片整什么乱七八糟的mimetype，直接设成text/plain就vans了，我非常怀疑这个file玩意是曾经写的试验脚本的遗留🤔脚本某处还用了一下awk，但它也只是做了一个在ls的结果里提取文件大小的事情，其实cut就能搞定，这里用awk实在是太大材小用了🤔当然还不是因为awk移植过去需要的依赖项多的批爆🤔

但当我开始移植cygwin版curl时，那才叫一个蛋疼，前后复制了十几个dll，它还是缺这个缺那个🤔最后，我干脆下了一个win版的curl.exe，一个可执行文件搞定所有东西（恼🤔之前不用bsdtar是因为它太慢，但curl又没有这种问题（当然它在单文件discord drive的实现里也是通过管道传数据的，但至少我目前没有观测到明显的性能下降🤔但cygwin版tar又没多少依赖项，我记得它最多依赖一个cygwin1.dll，不像curl（🤔

当然，这个最小系统或者最小环境的概念，在github actions里面也是能用到的，毕竟它每一个runner只有128GB总空间，如果我能用什么申必玩意将其清理到系统只占几个GB，那我不是可以拿它挂100GB这个级别的种子了？🤔甚至，如果我想的话，还可以拿它挂u2，或者任何不限制客户端数量的pt，或者任意bt🤔