multithreading discordbackups.20.03.30

没想到在缝合了包括discord drive脚本等一大堆脚本之后,我真的把多线程重新上传附件给做出来了,而且效果相对原版可以说是立竿见影,只需10个线程,拖ucc的冻鳗频道只花了28分钟42秒,拖ucc的mlp频道只花了两分钟48秒,现在还在测试nsfw频道,估计不会超过两小时🤔

总体来说对discord附件的处理,有两种方式,一种是在遇见附件的时候处理它并即时替换消息然后再写入dump文件;另外一种方式是先dump一遍消息,在此过程将需要重新上传的文件全部列出来(当然生成aria2链接的时候理论上来说就包含了所有信息,但那不够,我需要再生成一个metadata文件),然后在另外一个函数中将这些文件全部处理一遍,获取原链接和重新上传后新链接的对应关系,然后用sed命令实现替换,由于discord链接只有一个斜杠(可能还有双引号)是sed的元字符,把它转义掉即可

当然如果是py等高级脚本语言的话,理论上可以在dump消息的时候就将附件推到每个重新上传线程的待处理队列里面,这两步都可以并行,但bash并不是这种高级脚本语言,所以只能分两步走了

和discord drive相比,我还需要实现将大于8MB的文件交给nitro线程上传这个功能,考虑到实际情况,我强制规定数组0为nitro线程(即只有一个nitro线程),别的线程从1开始;接下来分配线程的时候只需要一个for循环就可以像以前一样干了

由于metadata文件里包括了附件的文件大小,遇到大于8MB的文件直接推给nitro线程,剩下的写个求余按顺序推给剩下的线程

另外我发现将for列举线程内文件的循环写在线程函数之外和之内都能正常工作,所以我还是写在线程函数之内比较好看;看来唯一需要注意的点几乎只剩下了将里面所有变量前面都加上local🤔

这么搞的话尽管从discord上下东西的速度是快了不少,但之后sed时就蛋疼了,毕竟现在它需要在一大坨消息dump里找到并替换附件url,时间复杂度瞬间从O(n+2m)变成了至少O(2nm),其中n是消息条数,m是附件数量,乘2是因为需要替换的地方有两处

比如搞ucc的nsfw频道时前两个步骤只花了可能一个小时,但sed替换时一秒钟才能替换1到1.5次,而需要替换的消息有一万多条🤔

这还真TM操蛋,不过除了移到本地linux外还有什么加速的方法?🤔可能需要重写一遍scheduler算法,直接将dump文件拆成线程个数份,然后除了需要扔给nitro线程的文件外,其他线程生成的新链接只需要替换它对应的dump片段,最后再将替换完成后的片段合并,这样时间复杂度就变成了O(t(n/t)(2m/t)),取决于sed可不可以多线程,前面的那个t也许可以去掉🤔

UPDATE:草,终于写完了多线程,无论(重新)分析、上传和sed替换都做了多线程,发现尽管sed时间缩短了十万甚至九万倍,但别的开销大了起来:

  • 由于不知道消息的具体数量,没法在一开始dump的时候分析,只能等dump完后分析,由于要保证前向兼容(获取原始aria2列表),需要重新分析(但这个也可以写成在分析阶段做,倒是没什么)

  • 最主要的是附件的分布并非均匀,所以有的dump片段就会比别的片段多些附件,甚至多出几十到几百件,这样别的线程需要等待这个线程

实测优化后的方法拖ucc的mlp频道居然比优化前多整整一分钟,就是在等那个多出来的线程;冻鳗频道花了26分钟32秒,快了两分钟多一点;我估计nsfw频道会是这种优化方法的最大受益者,毕竟之前光sed替换就花了67分钟49秒,而在优化后相同的过程(我光注释了上传的代码,然后生成了假的sed替换文件,如果不考虑附件不均匀导致的开销,可以认为是优化后的表现)只花了15分钟46秒🤔

由于我不小心ctrl+c掉了nsfw频道的dump过程,它sed到一半好像花了86分钟,我估计和discord交互的时间是52分钟左右🤔

对了,在比如死🐴管理一个小时后就要删聊天室的极端情形下,优化后的方法由于有重新分析和线程间不均匀等额外开销,搞不好会导致来不及备份完很多附件就消失了的额外风险,而之前的方法没有这个风险,而且由于给线程分配任务是按照余数的方式分配,它会尽可能均匀,最多只多出一个任务🤔

我的测试表明基本上在一万条消息以上,优化后的方法在时间上才有优势,而且会因为时间复杂度的二次方性优势更大

比如拖十万条消息和附件时,原来的方法可能要花以天计的时间来完成sed,当然此时已经和discord上面被删了的频道没有半毛钱关系了🤔

future

接下来我打算实现个迫真profiler,来标记出每个阶段需要花的时间,反正time命令的结果貌似只能输出到stdout或者stderr,如果设置重定向的话恐怕所有东西都从屏幕上消失了;我要么查下吧

然后就是想办法实现备份整个guild的脚本了,只需要列出所有channels,然后设置好每个channel对应的参数,然后就可以调用这个脚本了;主要是需要备份整个guild的时候情形都非常极端(比如旧/r/megatan即将被删前几个小时),时间真的很珍贵,估计所有频道都得设置成仅文字或者旧多线程方法

另外我需要想办法测试下一个频道被删之后里面的附件能保存多少时间,我看哪天想办法设计个实验,但现在还是算了吧

附录

用优化前方法拖mlp频道时间:

real 2m48.221s
user 1m38.277s
sys 1m26.461s

用优化后方法拖mlp频道时间:

real 3m19.677s
user 1m35.828s
sys 1m31.185s

用优化前方法拖冻鳗频道时间:

real 28m41.908s
user 16m8.481s
sys 14m10.055s

用优化后方法拖冻鳗频道时间:

real 26m32.508s
user 13m26.061s
sys 13m55.378s

优化前nsfw频道执行sed替换所用时间:

real 67m49.196s
user 33m38.716s
sys 31m18.762s

优化后nsfw频道重新分析、执行sed替换等所用时间:

real 15m45.703s
user 10m1.709s
sys 17m54.682s

优化后拖nsfw频道所用时间:

real 67m12.181s
user 35m12.408s
sys 40m22.244s

至于优化前的时间,反正我懒得测,当然也不一定(bruh

UPDATE.20.04.12:在vultr 512MB内存vps上拖ucc的迫真赛博监狱频道所用时间(由于司马cord不支持ipv6,我只能多花点钱上个ipv4实例):

real    12m16.441s
user    3m50.691s
sys     3m23.343s

discordbackups.20.03.29

我居然完成了备份discord的脚本,之前写的那个是水货,它只支持50条为单位dump,而且完全没法判定什么时候结束循环

于是我重新写了一个

当然和我的其他discord项目一样,它还是受到了某聊天室环境的影响,这次是ucc

I gaycar

garcar原名gaker,是个加拿大小屁孩,最喜欢干的事情就是在交通工具频道之外的地方,尤其是anime频道,刷交通工具的图片,难怪叫做gaycar;在我调查anime频道的历史时,我发现一开始几条消息就能看到gaycar的杰作了,可见这个频道建立的时候就受到了很多人反对;我现在总算明白为什么这个频道无论什么时候都有一群animehaters在那儿作妖了,原来这是它的优良传统啊(手动滑稽

在ucc这么一个活跃成员连20都不见得有的地方,一个人渣的出现对聊天环境的破坏比hrpc这种地方要严重得多,通常我管理这种小型聊天室的时候我会仔细审核成员的,然而raymond chan并不这样想,他出于猎奇能将drate chan这种苏卡放进nsfw频道,他当然也能干出留gaycar到处破坏这种事情来,而且更草的是,gaycar现在还是ucc狗管理之一

当然整个ucc的传统就是raymond chan瞎鸡巴搞,下面的人用过激的方式回应,无论在anime频道刷飞机还是在nsfw频道刷飞机都是如此🙃

ucc其实还有更过分的animehater,比如那个叫做jono的傻逼,是raymond chan的直系手下;某天raymond chan突然在anime频道里面挂起BJK的几十条消息,都和某件(二次元之外的)东西的娘化形象有关,jono这个娘炮最讨厌的就是娘化了,比如ucc就有条屑rule:

{"id": "667413725166305290", "type": 0, "content": "<@&279572070281773056> posting UCC \"chan\" will result in a suitable punishment.", "channel_id": "406933309189521409", "author": {"id": "223865652463534091", "username": "Jono(JSalty254)(CTzen)", "avatar": "6967c71ceccc1184bc518cef2bd638f9", "discriminator": "8331"}, "attachments": [], "embeds": [], "mentions": [], "mention_roles": ["279572070281773056"], "pinned": false, "mention_everyone": false, "tts": false, "timestamp": "2020-01-16T17:03:52.027000+00:00", "edited_timestamp": null, "flags": 0}

raymond chan挂出那些BJK的娘化形象发言就是为了拿jono取乐,草,这个troll狂魔为了troll人真的连亲妈都不要了,自己人都不放过;然后BJK就被关禁闭了,此时我感觉这事情是anime频道被橄榄的前兆,吓得我赶紧去写脚本了

II attachment reuploadin’

如果jono这些司马玩意真的准备橄榄anime频道,我估计它里面的附件也会回归虚无,所以我必须想办法存储它们,至少在discord的语境下(毕竟我已经写了那么多别的东西上传discord的脚本了),只需要将它们找出来,重新上传到一个在我掌控之中的频道里去,然后在消息备份里替换掉链接即可

而且保险起见,用webhook上传是最安全的(但用普通账号也没有遇到过被橄榄的情况,我从18年搞futaba.sh起就用nanakolover往我自己的guild里面塞了十万甚至⑨万张冻鳗色图,都没被橄榄),当遇到比8MB大的文件时,这部分文件就可以用nitro账号传了,既然是消息及其附件备份,我肯定不会像discord drive那样弄分卷压缩包这种操蛋玩意

还好ucc除了我外没人上传什么大文件,所以不会出现比我的nitro等级支持的最大文件体积(50MB)还要大的文件

为了能在discord返回的消息里面找到附件,我们需要知道每次discord返回的东西其实是个json数组,去掉数组前后的方框后,它剩下的是以逗号隔开的json对象,一个对象对应着一条消息,将对象与对象之间的逗号变成回车,就可以将消息分割成行,然后直接存储或者用for循环处理了;问题是}, {不见得是消息对象之间的特征,有时候它还是reaction列表之间的特征,有时候它还是附件和附件之间的特征(因为它们都TM是数组),所以我最后在后面加了id和type之后,它才终于能够只分割消息对象了,体现就是一次抓取消息最多只处理50条,如果计数出现了51,那它肯定把什么不该分割的东西分割了🤔

由于我们成功地将消息分成条了,除了获取附件信息外,还能精确获取每条消息的id,从而断点续传和增量备份也成为了可能,前者只需要在第一次抓取时设置before参数为上一个文件的最后一条消息id即可,后者只需要搞到上一个文件的第一条消息id,然后在脚本运行过程中加一个判断,如果当前消息id等于这个消息id,直接退出脚本,这样就完美地只处理了最新的部分🤔

至于附件重新上传,我不清楚怎么可能,但discord一条消息真的可以带多个附件,它们会存储为一个数组,用grep将数组那部分提取出来后,去掉数组前后的方括号,然后将}, {替换为}\n{即可,这次里面没有再嵌套数组了,直接替换即可,然后写个for循环处理它们

按照惯例每一个下载的附件会放在临时文件里,然后用for循环上传临时文件夹里的文件,尽管我写了for循环,但它只会被循环一次,毕竟里面才下载了一个文件;至少它比其他的写法看起来简单很多🤔

bash里面没有do-while循环体,所以只能先do一次(curl抓取50条消息,按照设置有直接抓取最新的或者抓取指定id之前的),然后进行while判断,循环结束(没有新内容拖)的标志是discord返回一个空数组[],非常简单,而且也符合逻辑,比如对一个已经拖完的dump实行断点续传,它第一次请求返回的就是空数组,使得整个过程都不会开始🤔

ps. 用正则表达式来处理json,尤其是像discord消息这种对象套着数组又套着对象的json不是什么值得推荐的做法,正确的做法是调用专用json解析程序,比如jq;但我的所有discord脚本设计时就是为了能在ibm cloud这种什么都没有的小🐔🐔上跑,所以只能写成这个样子了🙃🤔

III deployment

实测拖anime频道花了两个小时半,mlp频道可能花了半小时吧,毕竟有大量附件重新上传的过程;但拖general和pictures频道时我没有使用重新上传,很快就完成了;现在我在尝试完全备份nsfw频道,毕竟死🐴白左raymond chan经常威胁要删掉nsfw频道,而且ums的nsfw频道的确被删了(毕竟那儿白左至少有三个🙃

至于dump大小,anime频道大约有1.5万条消息,dump有8.6MB;mlp频道有1478条消息,dump有966KB;pictures频道有两万条消息,dump有12MB;general频道有17.6万条消息,dump有87MB;nsfw频道有6.7万条消息,dump有38MB;考虑到discord消息高度冗余,压缩起来非常容易,哪怕包含general频道的dump了,它也能压缩成两个普通用户能上传的包🤔

对了,对于原来脚本就有的重新上传回去羞辱狗管理的antics,我给它加了一个greta笑话生成器,用来取代原版里小号可能用不了的嘲讽表情合集;最经典的greta笑话内容是两个萌妹和greta困在沙漠里面,我写了一个数组用来枚举萌妹,然后用随机数下标选择萌妹,这样就非常的草了🤔

function gretajoke {
    cuties=("Ann" "Chie" "Marie" "Yukari" "Fuuka" "Futaba" "Hifumi" "Riley" "Cosette" "Alice")
    cutie1="Cosette"
    cutie2="Cosette"
    while [ "cutie1" = "cutie2" ]
    do
        cutie1={cuties[((RANDOM%{#cuties[@]}))]}
        cutie2={cuties[((RANDOM%{#cuties[@]}))]}
    done
    echo "cutie1 chan,cutie2 chan, and Greta Thunberg were all lost in the desert. They found a lamp and rubbed it. A genie popped out and granted them each one wish. cutie1 chan wished to be back home. Poof! She was back home.cutie2 chan wished to be at home with her family. Poof! She was back home with her family. Greta Thunberg said, \\\"How dare you fucking call me Greta Chan! \\\""
}

草,我发现它这玩意有时候会出500错误,导致脚本无限循环;所以可以考虑写个迫真异常处理,如果500的话就不停请求直到不是500为止,当然这玩意不像py,每个请求都能返回一个对象,里面可以查返回码,好在discord的500和它的空数组一样是一段固定文字,请求下面写一个while循环即可,通常情况下这个while循环压根就不会执行🤔

当然我还发现它一开始的sed替换写错了,导致保存下来的json里type后面出现了两个冒号,不过这个好修复,由于只有type后面有两个冒号,一个sed -i就够了🤔

IV antics

我在ibm的小🐔🐔上跑起了这个脚本,跑的是只保存文本模式,感觉还是要慢一拍的,每秒大约只能处理四到五个消息(与此同时我的vps可以一秒钟处理50个),可能是因为它的CPU太弱吧,毕竟它处理每一个消息需要调用好几遍grep和sed

但至少我可以在ibm小🐔🐔上跑,这样我折腾的那么多正则表达式可以说终于得到了回报(迫真

V assumptions

我猜测无论我疯狂20线程上传东西,还是不设置暂停时间地疯狂下载东西,discord仍然没有橄榄我的小号,而当我用web端时我的账号却经常被橄榄,最重要的一个原因是discord利用一个叫做science的api来监测部分行为,而我用bash的时候压根就不会用到science,discord顿时眼瞎了,失去了橄榄我需要的感官(手动滑稽

当然这是毫不靠谱的猜测,还是用webhook保平安吧🤔

接下来我打算写一个更加强力的玩意,用多线程来完成附件重新上传的过程,已知附件大小也在消息json里面,可以找出来并按照大小归类到某个线程里面(一个nitro线程、若干个webhook线程)

untersona.20.03.24

我打算做个perusona的parody game了,具体来说是将unterganger梗和perusona缝合到一块,然后尽可能迫真复刻perusona3movie的名场面,然后再加上大量unterganger圈子里的私货🤔

当然我知道做一款游戏非常不容易,比如在此之前我只是写了几个discord脚本而已,这游戏我现在连技术路线都没确定

是做成2d还是3d?用什么引擎?unity?除了迫真戏仿perusona的桥段外,它的背景如何设定?unterganger里的谁可以做主角?要不要设定可定制角色?又如何做它们?会不会或者要不要做成hentai游戏?要不要做些模拟制作元首视频的模拟经营类小游戏?

我估计光列举计划就要花掉一个月时间,按照软件工程的惯例(迫真),我应该先搞一个项目管理的框架,它最好能在一个网站上挂起来,然后用它跟踪项目,如果可能的话甚至可以托管项目文件,尽管我觉得没什么卵用

我上大学的时候可没有学过什么游戏项目管理这种东西,所以对于游戏工业的绝大多数东西我只能瞎鸡巴猜,比如这个untersona,我现在最多只能尝试写点脚本(不是脚本语言的脚本,而是电影里的那个脚本

总之缺的东西非常多,但如果我能设法做完它们,而且是一个人做完它们,我对大型项目的驾驭程度绝对能更上一层楼,而且这个大型项目不止开发个游戏,还有其他类型的大型项目,比如迫害/r/p5的管理团队之类的

在转移到正式的项目网站之前,我先暂且试图在这里列举一些提纲之类的东西🤔

草,我还真发现了一个项目管理的开源应用,所以打算搞个域名来托管它了,当然我可不像hrp那个憨批一样用自己的信息填whois然后被人whois出道,我打算填李志强的信息上去,什么地址电话啥的都全了,甚至连邮编都能查到,除非李志强刻意挡刀,不然将会有极大的生草效果,那帮personafags废物可以随便出道我,然后我来众筹机票让他们飞到台湾去真人快打李志强🤔

然后我发现.live域名的续费价格简直高得离谱,32美元,外加上另外一个域名我tm需要53美元续费,现在汇率已经7.1了,这tm就是将近400🙃

当然那是五月份的事情,尽管k-kawaii yukari chan is my waifu,但到时候要不要弃用这个域名换一个新的还在考虑;其实别的还好,主要是续期letsencrypt证书需要设置CAA,而且我的vesta是旧版所以没法自动化,而且我现在已经上了cloudflare,所以我懒得操心ssl证书的事情了,换域名的话cloudflare那边恐怕不好折腾;另外我看z0d.eu能不能设成ns记录(我记得新的freedns帐号好像不行了,而且更蛋疼的是我的几个小号不知为啥已被橄榄了),设一个,然后把项目管理网站挂上去,等我真的开始做这个屑游戏时再买一级域名🤔

鬼知道,设置一个项目管理网站可能还是太夸张了吧,我有没有动机做这件事情现在都不太确定,昨天晚上我随便找了一个申必代码解锁了逼乎,所以我在逼乎perusona板块口嗨了一晚上,但真的做游戏还是太触了

futabruh.20.03.20

这几天在玩四海兄弟3,这破游戏经常闪退,有时甚至还会蓝屏或者直接重启,我以为是某个元件过热所致,但我检查过所有传感器,温度都是正常范围;但今天它闪退的次数实在是过多,我玩个偷车的支线甚至车快到据点了,电脑直接重启,感觉那些关卡我好像试了不下十次甚至九次🤔

我感觉是内存问题,插上另外四条内存,这下好了,它直接开不了机了;如同我折腾R4E那样,我随便换了下内存,最终无论怎么折腾它都只能识别出三条,而且闪退问题仍然没有解决;甚至某些时候登录到系统之后就开始蓝屏🙃

我猜测上次主板直接翻转180度摔到地上也许对其部分内部电路造成了难以估计的损害,此时恐怕只能插ecc内存了🤔

还好我之前搞x86玩具的那四条工业垃圾一般的4GB内存(加起来也只有100块钱)被我带上了(而我却忘了带主机上的16GB内存,但我怎么想到在家里还能玩寨板?),赶紧插上看能不能用;那四条内存好像没法随便插,那个带马甲的海力士内存必须插4号槽(还是1号槽来着,这主板连个sepc都没有),不然开不了机;但如果能开机的话,那它是相当稳定的,比如我玩了可能是两个小时的游戏,一次闪退都没有发生,我感觉好像又回到了使用hp工作站主板的时候

但这16GB内存也太たま少了吧,一个四海兄弟3就能占掉4GB,再开几个firefox开个虚拟机,我估计内存就要爆炸了;现在32GB的ecc好像降到了356还是365来着,赶紧买上四条再说,最多我问下卖家4Rx4的14900L能不能用在山寨x99上

ps. 将低频率的ecc内存插入设置为高内存频率的系统后,会发生的事情之一便是直接卡得没法用;哪怕可以用,aida64的内存速度测试也没法完成,会无限卡🙃

UPDATE:悲报,那个32GB的4R*4 14900L内存条果然没法用,怎么改设置都不行,放弃折腾了,退货,然后买四条16GB的2R*4 14900R🙃

当然如果我哪天钱多得没处花了,我可以考虑买8条2666的DDR4,这样我也就可以使用个正经主板了,比如hp的z440主板就挺不错,还比华南的寨板便宜(?

然后插上8条DDR4的32GB内存,直接256GB内存,爽死了,整个系统都可以RamDisk化🤔而且关机前都可以保存回固态,其实完全可以像VMware处理虚拟机的内存那样,随时都保存快照,这样就可以在关机前尽可能快地保存东西,尽可能同时享受RamDisk的速度和固态的非易失性🤔我记得很多RamDisk软件有这种设置,但整个系统都RamDisk化我还没有尝试过🙃

b r u h c o r d.20.03.13

现在discord搞几个小号可真たま难,有时候刚注册完就强制电话验证了,有时候注册几个小时后才需要强制电话验证,反正以这个概率我们可以认为discord完全就是需要电话才能用了(老账号除外

然后discord还要摆出一副像17年那样的欢迎各路人士随便注册(甚至现在都可以直接在邀请链接里面填用户名然后直接创建账号)的迫真白左模样,实在是让人哭笑不得

所以我来做几个实验透透discord的🍺

实验一

我先使用我上次买的一个qq号的邮箱注册个小号

然后搞到auth或者token,对于什么都没有的新账号来说直接在firefox开发者选项的存储、本地存储里面就能找到token,不用抓包

然后上bash大法:

function altantics() { # 1 = auth,2 = alt number
    curl 'https://discordapp.com/api/v6/users/@me/settings' -X PATCH -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0' -H 'Accept: */*' -H 'Accept-Language: en-US' --compressed -H 'Content-Type: application/json' -H "Authorization: 1" -H 'Origin: https://discordapp.com' -H 'Connection: keep-alive' -H 'Cookie: __cfduid=d34b57750a8621dabd797ce74bfc579ef1584047884; locale=en-US; __cfruid=2b1a676e24e573415b1d55769aa6d0f4b68cea0a-1584047889' -H 'TE: Trailers' --data '{"locale":"en-US"}'
    ./discordfilehosting.v7.sh --antics "1" futabruh futabruh futabruh alt2.conf 32
    curl 'https://discordapp.com/api/v6/users/@me' -X PATCH -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0' -H 'Accept: */*' -H 'Accept-Language: en-US' --compressed -H 'Content-Type: application/json' -H "Authorization:1" -H 'Origin: https://discordapp.com' -H 'Connection: keep-alive' -H 'Cookie: __cfduid=d23c3aae32eb5dbb13cbfdf9dadc976661584047531; locale=en-US; __cfruid=955decf5551e3d1a15f9b51d952ac1a623c88963-1584047534' -H 'TE: Trailers' --data '{"username":"leachan'"2"'","email":"leachan'"2"'@saggyboobs.com","password":"[insert password here]","avatar":null,"discriminator":null,"new_password":null}'  
}

这样,我们就可以批量搞小号并改名成完全不存在的邮箱了,而生草的是那个qq邮箱居然能重复用(因为在验证邮箱之前可以随便改邮箱),实测我注册到第⑨个小号的时候才出现了我的脚本跑到一半就被风控的结果

实验二

在此过程中它生成了32的不知道多少倍个webhooks,我们来测试下当创建guild和webhooks的小号被风控(注意,不是橄榄)之后,这些webhooks能不能用

从只有一半的第⑨个webhook conf里面提取最后一条链接:

https://discordapp.com/api/webhooks/687774052252909569/on5bdVDOJJCOIbyV2_U8lLIaeIe2daM0wwwqVH3xeCq6KBDkWorQSrP6ybCUp1UhzkUo

然后随便找个discord image hostin’客户端上传个东西:

[上传过程略]

实测它完全能上传并返回预期的discord外链

结论(迫真

discord网盘的稳定性,至少基于webhooks的版本,得到了进一步的验证,只要确保guild owner的小号不被橄榄(一般来说discord账号很难被橄榄,尤其是这个小号加入了ao多聊天室而一句批话都没说过时),哪怕它被司马cord给风控了,它创建的所有webhooks都能正常使用,而我的discord网盘脚本是以discord webhook上传后的返回值来获取文件链接的,字面意义上的和discord账号没有一毛钱关系,完全不影响discord网盘所有功能的运作

phones

现在还有没有接码平台啊,我还是需要搞一堆discord小号的,用来toiletgang或者迫害perusonafags或者别的事情

wowwtf.20.03.11

卧槽,我发现x99系统居然支持睡眠啊,不像渣渣x79

但这个主板还是有点毛病的,比如睡眠之后居然没法像笔记本那样就用键盘或者鼠标唤醒,而是需要按下电源键;但更蛋疼的问题是唤醒之后风扇会狂转,直到下次重启之后才能恢复设定的低转速,这就非常蛋疼了,搞不好我只能尝试去买个物理调风扇转速的玩意,有吗?

data recovery.20.03.02

我去,那个司马易驱线在搞乱了我固态的分区表后,居然连那个5mm硬盘都不放过,但这次我发现用dg居然能恢复出来,它的智能读取分区功能不仅可以读出来原样数据,连目录结构都能保留,实在是太强了

然而我的那个版本dg没有破解完全,所以没法恢复,所以我只好再找个dg版本

其实dg是有加密狗的,难怪破解版dg都有这样那样的问题,比如数据检测出来了恢复的选项却点不了,估计是下了若干个反破解断点

但在我寻找dg破解版的过程中,我发现了dg居然还有海外版,而且海外版居然没使用加密狗,这样这玩意就没啥难度了,由于dg没有在线激活,只要带了注册信息就是完全的专业版,比adobe全家桶还要巴适

这样,我就用着英文版的dg将那块硬盘里的所有数据导出来了,文件的时间戳至少是完整的,但文件夹就不是了,本来能保住文件夹时间戳的软件也只有winrar和部分全盘备份软件了,而dg不是其中之一

好了,这次事件的教训无非就是哪怕这种盘也得接阵列卡上,至于那块接阵列卡上的固态,里面只有点音乐了,可以转移到5mm硬盘上;其实我买这破玩意就是为了放些固态放不下的东西,而那些服务器机械硬盘由于没有散热系统,我必须用的时候才会插上