search

XUANXUQAQ / File-Engine

An app launcher && efficiency tool
MIT License
530 stars 44 forks source link

尝试单独启用fileSearcherUSN但是发现建库失败 #15

Closed panwangwin closed 3 months ago

panwangwin commented 10 months ago

image 报错如下，好像是无法找到handle？

panwangwin commented 10 months ago

利用管理员权限启动即可，但是会报 image 这个Priority map是要提前配置到sqlite中吗？

XUANXUQAQ commented 10 months ago

是的，fileSearcherUSN会读取数据库中的priority map来根据文件后缀对结果进行分类。 https://github.com/XUANXUQAQ/File-Engine/blob/f2a9e745bab8b17491a84774b6f097bd52f872bd/src/main/java/file/engine/services/DatabaseService.java#L1220 下面是初始化priority map数据库的位置。 https://github.com/XUANXUQAQ/File-Engine/blob/f2a9e745bab8b17491a84774b6f097bd52f872bd/src/main/java/file/engine/services/utils/connection/SQLiteUtil.java#L437

panwangwin commented 10 months ago

https://github.com/XUANXUQAQ/File-Engine/blob/f2a9e745bab8b17491a84774b6f097bd52f872bd/src/main/java/file/engine/services/utils/connection/SQLiteUtil.java#L450 那这边主要priority的是这个函数里的这些文件后缀？然后其他的文件都是defaultPriority 0？

XUANXUQAQ commented 10 months ago

https://github.com/XUANXUQAQ/File-Engine/blob/f2a9e745bab8b17491a84774b6f097bd52f872bd/src/main/java/file/engine/services/utils/connection/SQLiteUtil.java#L450

那这边主要priority的是这个函数里的这些文件后缀？然后其他的文件都是defaultPriority 0？

是的，其实还有一个dirPriority是-1，所有文件夹都是-1。

panwangwin commented 10 months ago

Thanks! close the issue

panwangwin commented 9 months ago

尝试利用fileSearcherUSN建立索引，但是耗时过长？我大概建了1个小时也没建好。我利用everything的话大概只需建立不到半分钟左右？

XUANXUQAQ commented 9 months ago

尝试利用fileSearcherUSN建立索引，但是耗时过长？我大概建了1个小时也没建好。我利用everything的话大概只需建立不到半分钟左右？

大概率是你的参数有问题或者失败了，fileSearcherUSN建立索引时间也在半分钟左右

XUANXUQAQ commented 9 months ago

fileSearcherUSN在运行前需要一个MFTSearchInfo.dat文件指定索引的信息，文件内容如下

C:\,D:\,E:\,
D:\File-Engine\data\data
c:\windows,

第一行为所有需要索引的磁盘，第二行为索引数据库存放位置，第三行为忽略索引的文件夹 索引数据库存放位置还需要提前在数据库索引存放位置下新建cache.db，建立好priority表。

简单来说，就是要在fileSearcherUSN.exe的同一目录下新建MFTSearchInfo.dat文件，并写入索引的信息。 然后在索引目录下建立cache.db，新建priority表，并写入后缀和优先级。如果嫌麻烦去魔改一下获取后缀优先级的map的代码就行了，代码位置在这里 https://github.com/XUANXUQAQ/File-Engine/blob/dd1f0b480b41d25eacf7dc000dfb7a87a7d32999/C%2B%2B/fileSearcherUSN/fileSearcherUSN/file_searcher_usn.cpp#L47 最后再启动fileSearcherUSN.exe即可。

panwangwin commented 9 months ago

image 感谢回复，我发现我确实有很多exception。但是我无法定位这些exception的位置。 我在data文件夹下配置了db。 image 然后我用sql初始化了priority表如下： image 然后也配置了.dat文件 image 能不能帮我分析下我如何才能定位这个exception？

XUANXUQAQ commented 9 months ago

image 感谢回复，我发现我确实有很多exception。但是我无法定位这些exception的位置。 我在data文件夹下配置了db。 image 然后我用sql初始化了priority表如下： image 然后也配置了.dat文件 image 能不能帮我分析下我如何才能定位这个exception？

这个exception是不用去管的，因为你是debug模式跑，所以vs会去捕获异常，也是因为你是debug模式，所以建立索引这么久，用release模式编译运行，索引建立时间在半分钟左右。 抛出异常的位置在这里 https://github.com/XUANXUQAQ/File-Engine/blob/dd1f0b480b41d25eacf7dc000dfb7a87a7d32999/C%2B%2B/fileSearcherUSN/fileSearcherUSN/search.cpp#L102

master分支的fileSearcherUSN是先把结果收集到concurrent_unordered_set中，然后再统一写入数据库。 在File-Engine-Core项目中进行了修改，不会收集到容器，直接写入数据库，就不会抛出这个异常。 https://github.com/XUANXUQAQ/File-Engine-Core/blob/96c33a34c3509632bcfd355559b9ec39354711fd/C%2B%2B/fileSearcherUSN/fileSearcherUSN/search.cpp#L31 其实经过我的测试，其实两个版本速度并没有什么大的差别。

还有MFTSearchInfo.dat文件最后一行忽略文件夹，不区分大小写，统一用小写字母，不然会匹配不上。要写

c:\windows
panwangwin commented 9 months ago

用了Release模式，确实很快！感谢回复和相关建议！

panwangwin commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

XUANXUQAQ commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

目前只用了USN日志建立索引，暂时还没有遇到过文件缺漏的情况。不过在大数据量的文件变动情况下，文件同步偶尔会漏掉一些文件，比如我steam更新游戏的时候，偶尔会出现文件同步的缺漏的问题，之前用Windows API ReadDirectoryChangesW就很容易出现，现在改为了监控USN日志改动情况有所改善。

panwangwin commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

目前只用了USN日志建立索引，暂时还没有遇到过文件缺漏的情况。不过在大数据量的文件变动情况下，文件同步偶尔会漏掉一些文件，比如我steam更新游戏的时候，偶尔会出现文件同步的缺漏的问题，之前用Windows API ReadDirectoryChangesW就很容易出现，现在改为了监控USN日志改动情况有所改善。

Just for discussion, 我在想理论上USNJournal会把文件的所有操作都记录下来?所以在遍历USNJournal的时候有一些已经删除的文件也被扫描到了，虽然可以不建立index，但是这样也会损失一丢丢效率。虽然MFT里也会有一些已经不用的文件信息，但是是不是利用MFT来建立索引的话是最快速直接的方式？USNJournal只用来记录变化。

XUANXUQAQ commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

目前只用了USN日志建立索引，暂时还没有遇到过文件缺漏的情况。不过在大数据量的文件变动情况下，文件同步偶尔会漏掉一些文件，比如我steam更新游戏的时候，偶尔会出现文件同步的缺漏的问题，之前用Windows API ReadDirectoryChangesW就很容易出现，现在改为了监控USN日志改动情况有所改善。

Just for discussion, 我在想理论上USNJournal会把文件的所有操作都记录下来?所以在遍历USNJournal的时候有一些已经删除的文件也被扫描到了，虽然可以不建立index，但是这样也会损失一丢丢效率。虽然MFT里也会有一些已经不用的文件信息，但是是不是利用MFT来建立索引的话是最快速直接的方式？USNJournal只用来记录变化。

理论上来说用MFT表建立索引确实会快一点，建立索引的时候内存占用也会更低。主要是我之前开始写的时候就是用的USN来实现的，有点懒得重构。

XUANXUQAQ commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

目前只用了USN日志建立索引，暂时还没有遇到过文件缺漏的情况。不过在大数据量的文件变动情况下，文件同步偶尔会漏掉一些文件，比如我steam更新游戏的时候，偶尔会出现文件同步的缺漏的问题，之前用Windows API ReadDirectoryChangesW就很容易出现，现在改为了监控USN日志改动情况有所改善。

Just for discussion, 我在想理论上USNJournal会把文件的所有操作都记录下来?所以在遍历USNJournal的时候有一些已经删除的文件也被扫描到了，虽然可以不建立index，但是这样也会损失一丢丢效率。虽然MFT里也会有一些已经不用的文件信息，但是是不是利用MFT来建立索引的话是最快速直接的方式？USNJournal只用来记录变化。

晚上睡不着，搜了点资料实现了，具体实现代码在这里，如果你有兴趣的话可以看看，后续我测试稳定了就合并到File-Engine-Core的master分支。

https://github.com/XUANXUQAQ/File-Engine-Core/blob/5130ad810e100db096c6535904d068db9e2e9d70/C%2B%2B/fileSearcherUSN/fileSearcherUSN/search.cpp#L433

下面是一些我找到比较有用的参考资料： Master File Table (Developer Notes) - Win32 apps | Microsoft Learn

如何读取NTFS的MFT记录 – LotLab

ParseNTFS/ntfs.h at master · DeDf/ParseNTFS (github.com)

FILE_NAME structure - Win32 apps | Microsoft Learn

panwangwin commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

目前只用了USN日志建立索引，暂时还没有遇到过文件缺漏的情况。不过在大数据量的文件变动情况下，文件同步偶尔会漏掉一些文件，比如我steam更新游戏的时候，偶尔会出现文件同步的缺漏的问题，之前用Windows API ReadDirectoryChangesW就很容易出现，现在改为了监控USN日志改动情况有所改善。

Just for discussion, 我在想理论上USNJournal会把文件的所有操作都记录下来?所以在遍历USNJournal的时候有一些已经删除的文件也被扫描到了，虽然可以不建立index，但是这样也会损失一丢丢效率。虽然MFT里也会有一些已经不用的文件信息，但是是不是利用MFT来建立索引的话是最快速直接的方式？USNJournal只用来记录变化。

晚上睡不着，搜了点资料实现了，具体实现代码在这里，如果你有兴趣的话可以看看，后续我测试稳定了就合并到File-Engine-Core的master分支。

https://github.com/XUANXUQAQ/File-Engine-Core/blob/5130ad810e100db096c6535904d068db9e2e9d70/C%2B%2B/fileSearcherUSN/fileSearcherUSN/search.cpp#L433

下面是一些我找到比较有用的参考资料： Master File Table (Developer Notes) - Win32 apps | Microsoft Learn

如何读取NTFS的MFT记录 – LotLab

ParseNTFS/ntfs.h at master · DeDf/ParseNTFS (github.com)

FILE_NAME structure - Win32 apps | Microsoft Learn

卧槽老哥你太nb了，我也在查资料尝试实现一下，结果看到你的回复，也太速度了，我去学习一下。 下面是我现在参考的一些材料，也供你查询： https://www.youtube.com/watch?v=q3_V0EJcD-k&t=331s https://github.com/libyal/libfsntfs/blob/main/documentation/New%20Technologies%20File%20System%20(NTFS).asciidoc https://harelsegev.github.io/posts/resolving-file-paths-using-the-mft/ 我的邮箱是ink_pan@hotmail.com，我在想能不能加你个联系方式，后续交流。 再次非常感谢你的回复！

XUANXUQAQ commented 4 months ago

Hi 关于这个建立数据库，我还想问下，这里面有用Master File Table吗？还是只用到了USNjournal进行索引建立，如果只用USNjournal的话会有缺漏吗？

目前只用了USN日志建立索引，暂时还没有遇到过文件缺漏的情况。不过在大数据量的文件变动情况下，文件同步偶尔会漏掉一些文件，比如我steam更新游戏的时候，偶尔会出现文件同步的缺漏的问题，之前用Windows API ReadDirectoryChangesW就很容易出现，现在改为了监控USN日志改动情况有所改善。

Just for discussion, 我在想理论上USNJournal会把文件的所有操作都记录下来?所以在遍历USNJournal的时候有一些已经删除的文件也被扫描到了，虽然可以不建立index，但是这样也会损失一丢丢效率。虽然MFT里也会有一些已经不用的文件信息，但是是不是利用MFT来建立索引的话是最快速直接的方式？USNJournal只用来记录变化。

晚上睡不着，搜了点资料实现了，具体实现代码在这里，如果你有兴趣的话可以看看，后续我测试稳定了就合并到File-Engine-Core的master分支。 https://github.com/XUANXUQAQ/File-Engine-Core/blob/5130ad810e100db096c6535904d068db9e2e9d70/C%2B%2B/fileSearcherUSN/fileSearcherUSN/search.cpp#L433 下面是一些我找到比较有用的参考资料： Master File Table (Developer Notes) - Win32 apps | Microsoft Learn 如何读取NTFS的MFT记录 – LotLab ParseNTFS/ntfs.h at master · DeDf/ParseNTFS (github.com) FILE_NAME structure - Win32 apps | Microsoft Learn

卧槽老哥你太nb了，我也在查资料尝试实现一下，结果看到你的回复，也太速度了，我去学习一下。 下面是我现在参考的一些材料，也供你查询： https://www.youtube.com/watch?v=q3_V0EJcD-k&t=331s https://github.com/libyal/libfsntfs/blob/main/documentation/New%20Technologies%20File%20System%20(NTFS).asciidoc https://harelsegev.github.io/posts/resolving-file-paths-using-the-mft/ 我的邮箱是ink_pan@hotmail.com，我在想能不能加你个联系方式，后续交流。 再次非常感谢你的回复！

可以啊，我邮箱是xuanxu233@outlook.com。