功能建议：
如果能实现 “.piece_part.bc!” 文件仅存储已下载分块减去已完成文件的差异就好了。当前软件行为是未分块对齐时，“.piece_part.bc!” 文件存储所有涉及文件边缘的完整分块，导致如果仅选择部分文件下载，分块大，文件数量多且分散时有大量空间被浪费。
关联： 2.19测试版 - #76 seldho 2.19测试版 - #79 seldho 2.19测试版 - #81 seldho 2.19测试版 - #83 seldho
我认为技术上可行，比如分块数据位置记录+差异算法，就是实现起来应该很麻烦且不兼容旧文件。
意思是只存储那不被需要的半个分块而不是整个边界分块？
是的，是这个意思。
而且我理解并不是那些 “半个分块” 不被需要，对于仅下载可以下载完成后丢弃，而下载后做种上传，所有相关分块都是必须的。
理论上确实可以 不过应该会很麻烦 还是扩展一下 边界文件的大小吧
现在的4G肯定是不够用的 但扩展到多少比较合适呢？128G? 256G?或者更多？
下载完成丢弃后无法二次检验分块哈希值，也就无法上传了，原理上无法实现，所以才有了区块对齐这个功能出现
嗯，想必也很麻烦，所以就是想到了顺便提一下建议。
我认为 “.piece_part.bc!” 文件不应该设置大小限制。或者也可以为了兼容 FAT32 文件系统，拆分成多个文件，每个文件不超过4GB。
大佬仔细看看，我的意思不是丢弃，而是不重复存储相同的数据，仅额外存储差异部分。
未分块对齐的种子才产生.piece_part.bc!，里面都是下载的数据。分块对齐的种子hash时自动填0无需piece_part.bc!
一个.piece_part.bc!的文件出现的最大值为64M 只会在同一个区块中存储相邻文件，可以在文件列表最右侧观察区块链接情况
.piece_part.bc!中所有数据都是必要的，并没有重复的数据
现在你的问题是.piece_part.bc!为什么会占用到4GB的情况，该如何复现
感觉这4G大小限制 可能就是为了兼容FAT32
从BC之前的情况来看对其他未适配的非NTFS系统文件 也会自动限制到4G大小
分片是个不错的方法 应该也不会有什么兼容问题
我的意思是下载完成的文件边缘与 “.piece_part.bc!” 文件的内容部分重复。当前软件行为是 “.piece_part.bc!” 文件额外存储所有涉及文件边缘的完整分块，造成空间浪费。而实际上最优的是仅额外存储与已下载完成的文件不同的数据。比如你可以试试下载[未分块对齐][完全随机不可压缩的数据][大量的][小文件]，仅选择下载部分文件并且不相连。完成任务后固实压缩整个下载的文件夹（包括 “.piece_part.bc!” 文件），结果是压缩率远小于100%（理论上极端情况下接近50%），说明下载完成的文件与 “.piece_part.bc!” 文件的内容存在部分重复。这显然是可以优化的。
注：我理解 “.piece_part.bc!” 文件的作用，分块对齐的意义。
（触发新用户回复数限制了，等了1天才发出来。
如果我没有理解错误的话，你是认为“.piece_part.bc!” 文件中的数据与已下载的文件存在重复了。
即“piece_part.bc!{区块1[文件1(123…).文件2(ABC)].区块2[文件2(DE).文件3(321)…]…}”与已下载的“文件2(ABCDE)”有重复。
希望优化成“piece_part.bc!{区块1[文件1(123…).01a].区块2[01b.文件3(321)…]…}”与已下载的“文件2(ABCDE)”的形式。（其中01a.01b为”文件2“的占位符）
是的，是这个意思。小分块倒还好，分块越大重复导致浪费的空间就越多。
1個讚