关于电子书等大型文件的存放处置讨论

[ghost]

我是这个仓库目前的主要维护者，在不久之前，#40 使用百度网盘链接将一部分电子书提交到了本仓库，目前在也有 #45 在效仿。出于以下原因，我个人比较反对这种存储方式

• 百度网盘以及其他的第三方网盘的分享链接并不可靠，贡献者可能出于种种原因在日后取消分享（如手贱点错了、账号因某些原因被封、版权方对第三方网盘提起诉讼等）
• 百度网盘对普通用户不友好，大文件强制用户使用客户端下载，其他第三方网盘甚至没有 Linux 客户端等网盘自身的缺点
• 本仓库在 README 中明确写道不应该上传盗版电子书/付费电子书、盗版/破解版/绿色版付费软件及其安装包，如果以一种公域可访问的方式对这些东西进行分享，可能会影响到仓库本身（道理同 盗版网站在只分享 magnet 链接或者网盘链接，并不直接分发盗版软件/电影本身的情况下，也会被认定为侵权）

也正是基于上述原因，我一直没有接受 #40 的申请，应该是某位已经毕业的学长看到 pr 好长一段没有被合并就代为合并了。

在过去的几年中，仓库的管理员睁一只眼闭一只眼合并了不少此类内容，说明存放并分发此类文件的需求是有的。因此我在此发起这个 issue，与诸位仓库的管理者和参与者一起讨论此类文件的托管及处置方式。

[Patrick-Star-CN]

是否可以推荐一种大型文件的上传形式，并将其于主 Readme 中特别标注。

[zhullyb]

* 百度网盘以及其他的第三方网盘的分享链接并不可靠，贡献者可能出于种种原因在日后取消分享（如手贱点错了、账号因某些原因被封、版权方对第三方网盘提起诉讼等）

* 百度网盘对普通用户不友好，大文件强制用户使用客户端下载，其他第三方网盘甚至没有 Linux 客户端等网盘自身的缺点

针对这两个问题，我认为可以通过构建一次云端备份来进行解决。我构想了一种使用 Telegram Bot + Telegram Channel 进行文件备份的方案，即每次遇到 PR 中有大文件上传的情况，都将文件使用 Telegram Bot 发送到一个公开的 Telegram Channel 中进行备份。一来文件的可靠性得到了保证，二来也解决了国内网盘对普通用户的体验过差的问题。

这一文件的推送过程可以使用 Github Action 完成，减轻维护者的负担。Github Action 的操作建议额外建立一个 Github 仓库进行。

唯一的问题在于缺少一种优雅的、可持续的方案让 Github Action 获取到需要推送到 Channel 中的文件。

[yyz98799]

* 百度网盘以及其他的第三方网盘的分享链接并不可靠，贡献者可能出于种种原因在日后取消分享（如手贱点错了、账号因某些原因被封、版权方对第三方网盘提起诉讼等）

* 百度网盘对普通用户不友好，大文件强制用户使用客户端下载，其他第三方网盘甚至没有 Linux 客户端等网盘自身的缺点

针对这两个问题，我认为可以通过构建一次云端备份来进行解决。我构想了一种使用 Telegram Bot + Telegram Channel 进行文件备份的方案，即每次遇到 PR 中有大文件上传的情况，都将文件使用 Telegram Bot 发送到一个公开的 Telegram Channel 中进行备份。一来文件的可靠性得到了保证，二来也解决了国内网盘对普通用户的体验过差的问题。

这一文件的推送过程可以使用 Github Action 完成，减轻维护者的负担。Github Action 的操作建议额外建立一个 Github 仓库进行。

唯一的问题在于缺少一种优雅的、可持续的方案让 Github Action 获取到需要推送到 Channel 中的文件。

首先问题没讨论直接把文件传到库里的情况。然后单为了解决前两个问题直接要求换od/gd，没必要这么花里胡哨。第三个问题简单处理成版权方无法通过文件名/文件指纹检索到就行，网盘本身都没有直接内容省察。同时使用者只要知道课程名字就不影响下载全部资料。

喜欢比较复杂优雅的处理方式的话，内网起个文件服务器，有版权问题的传了再给标识符。使用者默认都是工大学生可以访问内网；对版权方来说维权成本够高；也没传教师自己编写的资料，不用担心教师投诉，因此可以挂在精弘的服务器上。

[zhullyb]

首先问题没讨论直接把文件传到库里的情况。

Github 在不启用 git-lfs 的情况下我记得最大也就 100MB，网页版上传的限制很大，此外还会给仓库的维护带来负担。小文件存存也就算了，大文件是有必要在别的地方储存的。

然后单为了解决前两个问题直接要求换od/gd，没必要这么花里胡哨。

这需要取决于仓库的使用者是否具有国际互联网的访问能力。如果这一部分没有访问能力的群体也是仓库的目标受众，Google Drive 似乎是不可接受的方案，OneDrive 是一个可以考虑的方案。

第三个问题简单处理成版权方无法通过文件名/文件指纹检索到就行，网盘本身都没有直接内容省察。同时使用者只要知道课程名字就不影响下载全部资料。

听上去是没有问题的，但对于仓库的贡献者，具体需要进行哪些操作呢？

喜欢比较复杂优雅的处理方式的话，内网起个文件服务器，有版权问题的传了再给标识符。使用者默认都是工大学生可以访问内网；对版权方来说维权成本够高；也没传教师自己编写的资料，不用担心教师投诉，因此可以挂在精弘的服务器上。

这个方案是可以接受的，但内网服务器的架设不知道会不会非常麻烦。

[ygrzxc]

这需要取决于仓库的使用者是否具有国际互联网的访问能力。如果这一部分没有访问能力的群体也是仓库的目标受众，Google Drive 似乎是不可接受的方案，OneDrive 是一个可以考虑的方案。

第三个问题简单处理成版权方无法通过文件名/文件指纹检索到就行，网盘本身都没有直接内容省察。同时使用者只要知道课程名字就不影响下载全部资料。

TG方案一样需要梯子，并且现在的TG注册会屏蔽一部分国内号码。Github使用也一样需要。直接更换网盘类型解决问题。
用Hash Modifier等工具改md5和SHA-1可以修改文件指纹。

[zhullyb]

TG方案一样需要梯子，并且现在的TG注册会屏蔽一部分国内号码。Github使用也一样需要。

所以方案是构建一次 Telegram 的备份，保留原有网盘链接，而非仅提供 Telegram 文件。Telegram 公开 Channel 文件下载不需要注册登录，不登陆的情况下可以直接通过网页下载。

Telegram 注册屏蔽国内号码的情况我周边十多个人从没遇过，反而遇到过几次国内运营商/国产手机屏蔽验证码的情况。

此外，现阶段 Github 仍然只是半墙状态，非特殊时期在校园网等环境下仍然可以完整加载出网页。

用Hash Modifier等工具改md5和SHA-1可以修改文件指纹。

这个方案确实可以修改文件哈希，但如何确保版权方无法通过文件名检索到文件呢？是否需要在仓库内不直接提到书名呢？

[Cassifa]

建议直接禁止传电子书，1：文件太大；2：想看电子书的自有途径去下，不会来这里找书，传这里毫无意义。这里应该是跟工大强相关的才能传；3：有版权风险