你没明白我的意思。
我不是说不存剩下的半个分块，而是仅额外存储剩下的半个分块。比如对于文件末尾，计算分块校验可以合并文件尾部+剩下的半个分块。文件首部同理。当前软件行为是 “.piece_part.bc!” 文件额外存储所有涉及文件边缘的完整分块。
还有，最好到新帖交流。
区块未对齐的时候，分块为64MB的情况单个piece_part文件最大为64MB，你是怎么占用到4G的，有测试种子看看吗？
下载完成丢弃后无法二次检验分块哈希值，也就无法上传了，原理上无法实现，所以才有了区块对齐这个功能出现
52ebbc04b634a88996107b93cf26fc128b4845dd
未分块对齐，文件数量太多，分块又大。仅下载部分文件，只要有64个以上的选择的文件集不相连就会导致 “.piece_part.bc!” 文件大小应当超过4GB。
你这个种子任务复现了，原因是有多层级目录结构，导致piece_part生成目标是目录了
正确做法应是为目录里面的每个文件单独生成piece_part，而并不是针对整个目录
现在的做法是把所有的piece_part聚合到目录外的一个文件上，然后就出大于4G的问题了
每个文件都生成的话 岂不是会出现很多小体积的文件
这对读写性能会有影响吧 还是说只会在校验时存在读写性能问题
看开发者怎么修了，保持现状不变，检测ntfs格式可写入大于4G的piece_part也是一种解决方法
这个方法好
对于支持4G以上单文件大小的文件系统 使用更大的 piece_part
而对于不支持的则可以使用多个piece_part文件
话说分块也可以考虑升级到128M和256M了，让种子文件大小控制在1MB内，一些发布站不支持大于1MB的种子
就是256M这种大区块的种子，32位应该无法申请进程内存，32位单个exe进程占用不能超过1G
正常不会做这么大的种子上载吧…会被重点监视的…
网络文件宜小忌大…
128M的种子qb里面是支持
256M的qb支持吗
大区块网络传输性能更好，就算qb不支持256M
比特彗星也可以催一下开发者支持128M和256M，甚至加上512M 这样未来几年后就不用催更了，512M刚好对对应磁盘sata3的io上限，我觉得很合理
目前bc不支持制作128M分块的种子
但是可以识别并正确下载qb制作的128M种子
似乎这个分块大小不需要特别适配
只需要读取 piece length中的值的就行
确切的来讲是在图形界面中没有给出对应的选项
那128M和256M其实都不会是问题
有没有目录没有关系吧，选择部分文件下载都会导致在任务设置的子目录下的单个 “.piece_part.bc!” 文件存储分块数据。难道新版本改变策略了？
每个文件生成也是个方法，相比现状各有利弊吧。
或许也可以针对大分块任务（比如32MB及以上分块），每个分块存储为1个 “.piece_part.bc!” 文件，全部存放在任务设置的子目录下的1个隐藏文件夹内。小分块任务保持现状。也是个方法。
支持2GB分块的种子。那理论上未分块对齐的情况下，岂不是选择1个中间的文件下载就会出现 “.piece_part.bc!” 文件大于4G的问题了。
已经正常运行比特彗星几天，突然又偶现了一次，tcp突然莫名其妙端口丢失
还好新版增加了 network.check_port_interval_hour 功能，可以及时通知用户黄灯了，避免端口丢失后还判断成长效种子，该设置目前未默认开启，需要自己开一下
不知道这个定时重新检查端口没有随机偏移量
不然集中检查可能会对端口检测服务器造成较大的压力
提个建议，关于长效上传。
虽然长效上传可以限制总速度，但不能限制单个任务的速度，导致速度高的长效挤占了速度低的长效，不均匀。
所以，建议出个设置，限制每个长效上传的速度都不能超过设定值。