tag:blogger.com,1999:blog-971876119771204189.post3682888455586385892..comments2024-03-12T22:24:25.119-07:00Comments on Of Filesystems And Other Demons: Contexts in legacy filters and FSRTL_ADVANCED_FCB_HEADERAnonymoushttp://www.blogger.com/profile/04456600991354270152noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-971876119771204189.post-45617286353649881322011-02-10T01:27:31.779-08:002011-02-10T01:27:31.779-08:00Alex,
No my objection to sym links has nothing to...Alex,<br /><br />No my objection to sym links has nothing to do with contexts (my context dilikes are aimed at RDR, but thats another story).<br /><br />But you appear to have hit one of my hot buttons.<br /><br />The issue with symlinks is that IOCFSDH goes straight through them on the same volume. This allows shoddy code (the stuff that doesn't handle STATUS_REPARSE) to work just dandy, but it breaks code that wants to understand the name space.<br /><br />An example (there are many more, I know because every namespace aware filter I have ever worked on has needed work because of this).<br /><br />If I open /foo/bar/foo/jim and it says yes, then I have every right to assume that bar is a directory. So I may want to set up my datastructures like that. I may even want to open bar FILE_DIRECTORY. I can be sure that I won't enter a circularity when traversing it becasue NTFS doesn't alolow hard links to directories (I have work on filesystem that allowed that, don't ask).<br /><br />But in fact bar is a symlink and IOCFSDH has *SILENTLY HANDLED IT FOR ME*, further there is no way to know that without traversing the path by hand and looking at the names.<br /><br />Then a bit later I open /foo/fred/jim and that fails, but as far as the user is concerned there is no difference - fred and bar are both symbolic links but jim is off disk and I have to explain that they are different. How am I going to do that and pretend that I have a well engineered solution?<br /><br />I'm sorry, but that is just shoddy engineering. I've been there and I can guess why: it was added (easier under time pressure) to add a gross hack to one module than to fix a thousand others.<br /><br />As far as a filesystem is concerned an on disk symbolic link and a mount point at the same. They should have the same code to handle them. They don't and that sucks.<br /><br />It would have been *so* much better if IOCFSDH had be modified to return the reparse buffer and fail. Given that I would have even been OK with a "go through symoblic links" option..<br /><br />I'm not sure why ECPs and symlinks are related, but I'll guess that this allows known modules to workaround these issues..Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-8760874347299067662011-02-02T20:59:09.776-08:002011-02-02T20:59:09.776-08:00Hi Rod. I can't think of any particular unplea...Hi Rod. I can't think of any particular unpleasantness that symlinks introduce with regard to contexts. Or are you referring to them in general ? <br />I for one am grateful that they needed to add ECPs to implement symlinks or else i'm not sure we would have had them even now.Anonymoushttps://www.blogger.com/profile/04456600991354270152noreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-77068557748567446752011-02-02T01:39:39.088-08:002011-02-02T01:39:39.088-08:00Dont forget the mess that is symbolic links and al...Dont forget the mess that is symbolic links and all the work that Win32 and the IoManager do to make them almost impossible to deal with in a name aware filter (because they do not respect the reparse point rules)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-25396186313636508722011-01-31T15:26:00.176-08:002011-01-31T15:26:00.176-08:00Hi Lyndon! Thanks for your comment. This is a very...Hi Lyndon! Thanks for your comment. This is a very good point, I'll talk about the relation between a file, its links and streams in the next post then.Anonymoushttps://www.blogger.com/profile/04456600991354270152noreply@blogger.comtag:blogger.com,1999:blog-971876119771204189.post-43966434598929700732011-01-31T14:42:44.677-08:002011-01-31T14:42:44.677-08:00Alex,
This is a good post, but I find missing the...Alex,<br /><br />This is a good post, but I find missing the whole area generated by NTFS hard links, where the notion of a "link/name context" seems to be needed.<br /><br />Some questions the [mini]filter driver developer needs to contemplate:<br /><br />- Which name was changed in IRP_MJ_SET_INFORMATION/FileRenameInformation<br /><br />- Which name was (maybe will have been!) deleted in IRP_MJ_SET_INFORMATION/FileDispositionInformation (and "friend" FILE_DELETE_ON_CLOSE )<br /><br />The FileObject, FileObject->FsContext (aka FCB/SCB), model seems to be less than complete for these questions.<br /><br />There seems to be nothing in the "legacy filter" world other than brute force [normalized] file name (string) comparision.<br /><br />Then here also, filter manager also seems [to me, at least[ to comes up short in terms of assist for the mini-filter developer.<br /><br />Your thoughts, as ever, much appreciate.<br /><br />Best Wishes,<br />LyndonLyndonnoreply@blogger.com