jpippy / os-design Goto Github PK

1. 新增应用层交互完成端口需要DDK编译环境
2. 以后每次编译都需要DDK环境

1. 外发中打开adobe
2. 访问文件是 _UNICODE_STRING "\Program Files\Common Files\Adobe\Adobe 
PCD\pcd.db"
3. RelatedFileObject值无效
4. 名称提供器获取文件名时判断RelatedFileObject访问无效地址

1. 网络上
2. 以前也结果这个bug
3. 肯定是哪块权限处理不足

1. 一直认为不可能，所以一直没有去尝试过，直到有一天 ... 
ALEX says 

Alex Carp <[email protected]> Fri, May 14, 2010 at 10:03 PM
Reply-To: Windows File Systems Devs Interest List <[email protected]>
To: Windows File Systems Devs Interest List <[email protected]>
"I need to read the data before the IRP Create has been completed" as I
explained previously, this might be rather hard. It also doesn't answer the
question about what you are trying to do, it only explains what you think
you need to do, which is not the same thing.
You can return STATUS_REPARSE (or any other status for that matter) from
postCreate and you can also call FltCancelFileOpen on the file that was
opened and fltmgr will close it for you.
Thanks,
Alex.
[Quoted text hidden

1. notepad编辑后无法保存
2. 保存提示找不到文件

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

软件工程就是通过规范实现定义的，如果没有规范定义，也��
�没有软件工程这个概念了，软件工程不像建筑工程，有实体�
��的东西存在，所以从规范性文档出来的软件容易跟踪处理，

--- 不好意思， 我给自己个差评，尤其在软件工程方面。

1. 提前预研
2. 需要正式代码
3. 需要马上集成测试

 上海技术反应一客户测试文档外发，可以导出包内明文文件。包括亿赛通等目前测试其他厂商也都可以导出。但是用户不透露具体破解方法，也是一个开发类用户。
 如果文件关联进程是用户自己写的小程序，进程间通信我们是没有做防护。但用户是否使用这种方式不确定。

测试结果 

无UEM客户： 2：40
正式版本驱动： 6：40
NOSCAN     ： 6：50
DCC ： 5：30
CREATE：5：10
Create+dirctrl  |+ query都是 5：30

确认了以下情况
1. 无驱动是 3：30
2. 去掉POSTCREATE处理是 5：10， （感觉不准确）
3. 去掉所有IRP处理测试两次，一次是 5：30 ，一次是3：40

测试还是不准确， 客户6点下班 ，明天确认

1. 模块中附件线程功能块导致主进程异常；
  a: 这类型的功能线程是否需要放到主进程中处理，相关模块仅负责提供接口；
  b: 如果需要独立功能到相关模块，需要增加说明；
  c: 功能独立，出问题时主进程和模块之间并没有交互；
  d: 此模块的异常功能在一段时间后删除，从此不再提供此功能；   

2. 问题解决
  a: 这个问题持续时间约两年；
  b: 用windbg等工具很容易确认问题；
  c: 需求或者功能变动导致问题无法跟踪；

RE: name provider vs. status_reparse
Well, since we've already opened the can of worms :), there are a couple of
other things to consider when choosing between the two approaches.

I agree that reparse is a good solution for redirection. For virtualization
however it is a lot more complicated. However, if you're just looking to
implement some symlink-type solution then STATUS_REPARSE should be fine. 

While Razvan is certainly right when he says "you never know when another
filter decides to bypass your filter and sends the file object you own into
NTFS", this is a VERY serious architectural flaw in any filter and as far as
I know MS has stated that it will try to persuade developer of such filters
to fix their design (whatever that means... I imagine such filters will not
get the windows logo but there may be other things that I'm not aware of).
Also, although I have seen this behavior in the past, I've not run into it
in the past couple of years. As far as I know, the shadow file objects model
(i.e. taking ownership of the FILE_OBJECT) is the one MS recommends for
virtualization.

In terms of limitations of the STATUS_REPARSE method, here are a couple of
them off the top of my head:
1. it does not allow to virtualize file contents. For some projects this
isn't a problem, but for some it might be and it's a serious one. For
example, a deduplication solution that always reparses to the same file will
work as long as the file system is read-only, but if the requirement is that
someone can modify a de-duplicated file and that they receive their own copy
at that point, things can get tricky. 
2. if the virtualization is somewhat dynamic (so that \a\b will not always
point to \c\d but instead it can be changed to point to \e\f under some
circumstances) then you have the problem of out-of-sync handles. So some
handles for \a\b might point to \c\d on disk, while some will point to \e\f
and if some applications might use a file as a communication mechanism and
they might end up writing and reading from the wrong file. The same goes for
filters that use files for synchronization (I remember doing that in some
perl scripts...). 
3. clearly there is a layering problem, and two such virtualization filters
on the same machine will run into very interesting issues... Application
virtualization filters are pretty common these days...
4. there might be issues with namespace related stuff if you allow access to
a file through both names (if someone can open both \a\b and \c\d directly).
For example, implementing the name provider callbacks is going to be tricky
unless you can know which requests were reparsed and which were not, which
can be done in Vista and newer using ECPs, but is really hard to do for XP. 
5. if you reparse to a different device stack then any minifilter above
yours that calls FltCreateFile() with an instance and any legacy that calls
IoCreateFileEx() or IoCreateFileSpecifyDeviceObjectHint() with a device hint
(and all these are the recommended ways of doing it) will get a failure for
that create and might not function properly. 

Unfortunately, the shadow file object (SFO) model isn't as easy as
STATUS_REPARSE to get right, so hopefully MS will release a sample or OSR
will publish the source for the isolation filter they're writing about in
the NT Insider. There need to be more implementations of such filters before
the ecosystem adjusts to this (and filters that bypass other filters will
finally become too broken to be used at all). 

Ultimately though the decision is yours, my hope is that this will make you
make a more informed decision. 

Thanks,
Alex.

Liu设计的概要设计涉及到我过去两个月的预研结果，却没有��
�虑到我的代码，于是乎，他决定自己重新写代码，主要是功�
��是我预研的，为什么会有别人参与！不累的话，可以重新设
计，我并不反对。

向项目经理申请有Liu合并修改最后代码时已经确认Yuan会同意�
��既然同意了，为何还会郁闷？