能力值：
( LV2，RANK：10 )
|
-
-
2 楼
既然有个过滤驱动，完全可以在IRP_MJ_CREATE例程里通过IoStackLocation->Parameters.Create.ShareAccess过滤掉独占文件，不加入队列里
如果你不想这样，你试试扫描程序在处理文件时上个oplock,参考12dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Y4L8$3!0Y4L8r3g2H3M7X3!0B7k6h3y4@1P5X3g2J5L8#2)9J5c8Y4y4&6L8h3u0G2L8r3W2U0L8r3W2F1K9#2)9J5k6s2c8W2M7%4c8A6L8X3N6Q4x3X3c8@1L8$3!0D9M7#2)9J5c8Y4c8J5k6h3g2Q4x3V1k6E0j5i4y4@1k6i4u0Q4x3V1k6e0k6i4c8a6M7p5I4G2j5$3D9`.
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
感谢大佬回复，第一个方案不太符合我的需求，第二个方案我测试是可以的。感谢！
另外，如果放在内核做的话，有没有哪些可行的方案？
|
能力值：
( LV2，RANK：10 )
|
-
-
4 楼
在其他进程以独占方式打开文件前，如果没有设置oplock，扫描程序必须关闭正在处理的文件句柄，否则"会对程序的正常逻辑造成影响"是必然的
我个人理解的合适的关闭句柄时机是其他进程以独占方式打开文件时触发的IRP_MJ_CREATE：假设将除了扫描程序还有其他进程正在打开文件的情况也考虑在内，你需要ObfReferenceObject之类的函数获取文件对象的引用计数进行判断
如果引用计数的结果是只有扫描程序和当前正在独占打开的进程，那么驱动向扫描程序发送消息，扫描程序收到后关闭句柄（DeviceIoControl怕是不好用了，可以试试LPC:https://bbs.pediy.com/thread-261668.htm）最后设置Irp->IoStatus.Status=0使这次独占打开成功
不是大佬，菜鸡一只，再问就是我不知道。
最后于 2021-11-8 23:36
被sky5编辑
，原因：
|
能力值：
( LV2，RANK：10 )
|
-
-
5 楼
sky5
在其他进程以独占方式打开文件前，如果没有设置oplock，扫描程序必须关闭正在处理的文件句柄，否则"会对程序的正常逻辑造成影响"是必然的我个人理解的合适的关闭句柄时 ...
其实我原先的思路就是你说的这样，不过用的是DeviceIoControl，但队列没处理好，搞不定同步问题，等有时间再试试。多谢了！
|
能力值：
( LV2，RANK：10 )
|
-
-
6 楼
你好，这种情况可以使用minifilter单独维护一块ShareAccess，下发到文件系统驱动的ShareAccess可以适当修改，比如给进程FO原来的ShareAccess加上SHARE_WRITE或SHARE_READ等，文件独占的冲突主要是ShareAccess的问题，可以看看wrk中相关的代码。
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
hkx3upper
你好，这种情况可以使用minifilter单独维护一块ShareAccess，下发到文件系统驱动的ShareAccess可以适当修改，比如给进程FO原来的ShareAccess加上SHARE_WRIT ...
这个我倒是尝试过，在PreCreate中判断了权限并修改，不过测试的时候仍然有问题，也不清楚是我设置的不对还是什么原因。
|
能力值：
( LV2，RANK：10 )
|
-
-
8 楼
这个简单，创建一个fcb就完事了。类似于透明加密双缓冲（两个文件对象，一个管理明文，另一个自己捣鼓）方式。oplock这玩意一般是网络链接（smb）同步数据会用到，不过我没研究过oplock底层文件系统是怎么细致得运作的。
|
能力值：
( LV2，RANK：10 )
|
-
-
9 楼
库尔
这个简单，创建一个fcb就完事了。类似于透明加密双缓冲（两个文件对象，一个管理明文，另一个自己捣鼓）方式。oplock这玩意一般是网络链接（smb）同步数据会用到，不过我没研究过oplock底层文件系 ...
搞FCB有些过分复杂了，我觉得没必要，毕竟不是搞加解密。测试了下oplock机制感觉还行，能够处理占用问题。简单测试了几款杀毒软件，也就发现火绒做得还不错，不会出现占用问题，不会影响操作文件的进程独占打开文件。
|
能力值：
( LV12，RANK：385 )
|
-
-
10 楼
IoCreateFileSpecifyDeviceObjectHint + IO_IGNORE_SHARE_ACCESS_CHECK
IoCreateFileEx + IO_IGNORE_SHARE_ACCESS_CHECK
e46K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6C8L8%4g2*7K9s2g2V1L8$3&6Y4i4K6u0r3L8r3W2T1k6s2u0$3i4K6u0r3j5X3I4G2j5W2)9J5c8X3#2S2K9h3&6Q4x3V1k6D9K9h3u0V1M7Y4k6Q4x3V1k6o6L8%4m8&6c8X3W2D9k6g2)9J5k6h3y4H3M7l9`.`.
|
能力值：
( LV8，RANK：120 )
|
-
-
11 楼
Anowhere
搞FCB有些过分复杂了，我觉得没必要，毕竟不是搞加解密。测试了下oplock机制感觉还行，能够处理占用问题。简单测试了几款杀毒软件，也就发现火绒做得还不错，不会出现占用问题，不会影响操作文件的进程独占 ...
这么老的帖子。我这边有分享过oplock，可以看下 c1aK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0L8X3u0D9L8$3N6K6i4K6u0W2j5$3!0E0i4K6u0r3K9$3E0A6L8X3c8G2k6W2)9J5c8X3q4J5N6r3W2U0L8r3g2K6i4K6u0r3x3K6f1#2x3e0x3H3y4#2)9J5k6h3S2@1L8h3H3`.
|
|
|
|
