2 确实比较好目前的模式似乎和eMule比较相似 也是在启动时检索文件
这个其实不是什么问题 有请求的时候再更新索引 应该是最节省资源的
不知道现在是怎么处理重复文件的 eMule在计算哈希后发现是重复文件会跳过此文件
但是不会记忆这个重复的文件 下次启动的时候还是会对这个重复文件进行哈希计算
添加搜索功能确实很好 不过现在长效种子文件只能在专家模式下查看
也以后可以移到普通模式下？
2的话感觉更好，对后续其他功能开发的干扰小（好像有个专门的词汇形容这种优点，但我忘了）。
不过1的话，考虑到绝大部分用户都用的是NTFS文件系统，或许可以效仿Everything（不扫描文件，而是读取磁盘上的USN日志，建立索引）。
或者直接弄个高级设置，让用户选择是否全速扫描（感觉这个实现起来比较简单粗暴，不过用高级设置的人比较少）。
2的话不太好，我可不想看到有一个长效种子，但下载不了的情况出现，请求后发现对方文件已被删除，优先考虑取消扫描间隔或者自定义间隔最小0
楼上说的那个索引实现其实就是和2差不多，而且不能跨平台就没必要了
解决方法很简单 请求后修正显示结果即可
这样频繁的扫描大概是难以适应大部分设备的
尤其是叠瓦盘的存在 虽然理论上其读取性能损失不大 但是再既写入又读取的情况下
表现应该是好不了的
选择触发扫描的文件的时机是一个关键的问题
启动时自然要扫描一下 但在运行过程以什么频率扫描就成了个问题
我的建议是在下载完成一个文件的时候进行一次全面的或局部的索引更新
注意是文件 不是任务
而所谓的局部更新就是更新当前下载完成的这个文件的情况
而全面更新 就是检查所有已记录的文件 是否还存在
感觉局部更新会更合适 不然有多个文件同时下载完成的时候就会集中触发全局更新
感觉不太合适 如果读取USN日志的话应该不可避免的读取到其他文件
即那些不是由BC下载的文件 可能会有扫盘的嫌疑
现有版本是启动后延迟300秒才进行扫描，避免用户启动后立即退出导致无效用户
这个当前版本也算有，下载任务完成后，可以弹性更新立即作用为长效种子上传
其实这个长效种子扫描文件不会带来很大的开销，应该只是简单的对比了文件大小和修改日期
楼上那位网友也说了，，，期间没有任何性能占用
没有哈希校验过程？
校验这个是在制作种子文件的时候发生的
和下载文件后，如果种子文件内没有包含长效hash值（制作时没有勾选，或者其它BT客户端制作的的种子文件），才会进行校验来作用于长效种子，日志中会进行提示
同时如果未包含hash的种子，长效种子服务器上已经有其它网友首次校验过，后续的其它人也不会进行校验
确实 可以通过比对修改日期来判断文件在软件退出期间是否被更改过
若为更改则不需要重新进行校验
如果是这样的话确实可以提高一下检查速度尤其是启动时的检查速度
这样的话其他部分 其实目前不太需要修改 先提速一下启动时的校验速度
但是机械盘的工作原理是磁头，频繁去检查不同的文件大小等于说是在用4K读写速度运行磁头来回跳动到不同的磁盘扇区中，总之给用户高级设置自定义间隔就好了，和tcp发起间隔一样，最小值可以改成0ms，这样就能适合固态硬盘之类的硬件了
最简单的点开我的电脑，进入机械盘分区盘符，选择一个游戏文件夹右键属性，机械盘大概1秒能扫描到50-100个文件，固态盘一秒大概10000个文件
间隔时间为0ms，固态硬盘性能全开的时候，15万个文件作用于长效上传，扫描完成只需要15秒
机械盘性能全开大约为25-50分钟，符合楼上加载了20分钟的预期
也可以直接给个勾选的开关在这，“我电脑所有硬盘均为SSD”，勾选后把扫描速度提升到1w每秒（0ms不限制），不勾选则每秒50个文件（10ms-20ms）
我想如果只是提升首次启动时的校验速度的话 只需要调整一下并行检查文件的数量就行了
在高级设置中添加一个调整并行检查文件数量的选项 没有必要使用调整频率方法
我想长效种子应该尽可能保持低调 大部分的用户恐怕并不知道长效种子的存在
其大部分时间都是“偷偷运行的”
感觉这一步可以让彗星自动来判别（先用0ms的扫描间隔扫描位于固态硬盘的任务，再用保守的扫描间隔扫描位于机械硬盘的任务。）。
感觉【调整并行检查文件数量】等价于【使用调整频率方法】，多少路并行，就是频率乘以多少倍。
vps虚拟化下，如果是机械盘的大盘鸡，，系统上检测出来也是显示为固态盘，自动判断可能不太好
主要是不同硬盘不同系统在不同的条件下响应速度是不一样的
使用文件数量应该更容易量化
如果扫描前，把每个盘符都测一下4K随机读写速度，快得像固态硬盘的就视为固态硬盘，慢得像机械硬盘的就视为机械硬盘，似乎也行，虽然不够简练，但普适性好像不错。
其实【正在准备长效做种】的后台任务并不影响彗星的正常操作及使用，只是过程很长的话，看着不舒服。
想了一下，可以将两种方法结合起来。程序启动的时候，像种子市场一样在后台加载含有全部任务全部文件的sqlite数据库，用于界面的文件搜索。5分钟后再开始慢慢检查是否有文件被删除或移走，以保证长效上传信息的有效性。
目前两个任务扫描的间隔是1000ms，可以加个高级设置项来给等不及的用户自定义（间隔不宜小于100ms）
1個讚
好像明白了，也就是说文件之间是没有扫描间隔的，而任务之间是有扫描间隔的，我全部任务大概有1500个，每个任务间隔一秒，加起来就是二十几分钟了。
有点浪费硬盘io性能去查询db库，之前有反馈过虽然比特彗星把db加载到内存里了，但是读写的时候还是发生在硬盘，而不是内存中操作
会不会多此一举了
原来是按照BT任务来扫描的 这样其实也挺合理的
那通过调整每个任务之间的扫描间隔确实是个不错的方法
既然是在扫描的时候是按照BT任务来的 那在显示的时候其实也可以这样
现在的长效做种列表 有文件而无任务 只能看目录来判断文件所处的任务
可以将同一个任务下的文件聚合显示 就像是可展开的文件树那样
启动时读取的数据是都缓存在内存里的，数据有变化时还是得及时在工作线程里写盘，否则有数据丢失风险
长效种子是按文件来的，多个任务里的相同文件会合并，只保留一份记录
1個讚
确实跨任务的话 有相同文件需要去重 以任务为单位的话显示就是个问题了