tag:blogger.com,1999:blog-971876119771204189.post1310771260796765386..comments2024-03-12T22:24:25.119-07:00Comments on Of Filesystems And Other Demons: Problems with STATUS_REPARSE - Part IAnonymoushttp://www.blogger.com/profile/04456600991354270152noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-971876119771204189.post-43358617520079399722012-03-01T13:38:31.829-08:002012-03-01T13:38:31.829-08:00Thanks Rod!
For the record, the IO manager functi...Thanks Rod!<br /><br />For the record, the IO manager function Rod mentioned is IoReplaceFileObjectName.Anonymoushttps://www.blogger.com/profile/04456600991354270152noreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-61586357799087311712012-03-01T01:14:24.780-08:002012-03-01T01:14:24.780-08:00Alex,
Another excellent post, thanks.
A quick not...Alex,<br />Another excellent post, thanks.<br /><br />A quick note for the record - People doing the "slam a new name into fileObject->FileName and return STATUS_REPARSE", should also do a couple of extra things:<br /><br />- Use the IoManage function to do this to save eventual Verifier issues.<br />- Set Iopb->IoStatus->Information to IO_REPARSE. This latter is important since upper filters will (should - I met a couple at the latest plugfest including my own ) be looking at it to see their tag.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-25474768125535998832012-02-06T08:23:01.050-08:002012-02-06T08:23:01.050-08:00Hi Artem,
This is what I was talking about when ...Hi Artem, <br /><br />This is what I was talking about when I mentioned breaking the deduplication. The problem with doing it in preCreate is that there are many applications that open a file with write access in case they need to modify it (or in some cases the developers are just careless and open for write without needing to) which means that you'll end up copying a lot more files that necessary. I agree with your approach of copying the file on demand, but that is generally pretty complicated. Once you've copied the file you must redirect all operations to the new file (the one you've copied the original file to) which means you must be in a position to do that. For some operations (consider oplocks) it's going to be hard to move them to the new file (if you need to). Also, in either situation, you'll have to deal with the split-IO problem I mentioned above (unless you track all the handles open against the original file and when you device you must copy the file you move ALL the handles that are supposed to be moved and not only the one that's doing the write). <br /><br />Ultimately I'd say that for your decision it matters whether you must be more conservative (both in terms of performance and space) and so you'd want to only copy only when the modification happens (or will happen for sure) or you can afford to be less conservative and so you can just copy on preCreate. My choice is to copy on actual modification (and not in preCreate) but as I said before, that's more complicated to get right.Anonymoushttps://www.blogger.com/profile/04456600991354270152noreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-70820651474605356472012-02-06T00:08:37.556-08:002012-02-06T00:08:37.556-08:00Hi, Alex. Thank you for the article. Currently, I ...Hi, Alex. Thank you for the article. Currently, I am to develop legacy-filter that using reparse technique for forward original FS-operations to special folder - storage. <br />For me, seems there are also important question: when need perform copy-on-write operation for copied original file data to new file in storage? Two ways, I think: 1)in Create-op when it opens with modified access or 2)on demand - when operation perform (write, for example). I chose 2-nd way - on demand, because of performance issues. What you think about that?Artem Baranovhttps://www.blogger.com/profile/17963619118870289264noreply@blogger.com