[PATCH 1/2] include: Add ntifs.h with Reparse point related definitions and typedefs.(try 3)

[YongHao Hu]

Good point.


On 15/8/6 下午10:50, Pierre Schweitzer wrote:
> I can indeed see that example being used and explained everywhere (yet
> another [3]), but there's a clear contradiction between the MSDN
> documentation and these implementations.
>
> I feel like this has been some un-understood copy/paste code from M.
> Russinovich header that you pointed [1] and should no longer be used.
> You can clearly see from 3 that for their mount point, there are
> clearly using the IO_REPARSE_TAG_MOUNT_POINT. So, basically, what you
> expect in this case is REPARSE_DATA_BUFFER with
> MountPointReparseBuffer struct filled in the union.
As I can't find explanation in MSDN,  I also had a look on [3] before 
and created reparse point in wine like it.
> So, really, forget about that structure
> 'REPARSE_MOUNTPOINT_DATA_BUFFER', which is broken legacy from old days
> where such things weren't that much documented.
>
> Basically, if you want to have a look at mount point, you have a nice
> one on Windows 7+ (and perhaps Vista, I don't have any test
> plateform), "Documents and Settings" directory is just a mount point
> to C:\Users (provided you installed your OS to C:\ partition).
> So, basically, you have a reparse point (C:\Documents and Setings)
> which is tagged with IO_REPARSE_TAG_MOUNT_POINT, and it contains a
> "MountPointReparseBuffer" with a target to C:\Users.
> When you attempt to open C:\Documents and Settings (or anything
> below), on traverse, the NTFS driver will issue a STATUS_REPARSE on
> the "Create/Open" operation and will return a REPARSE_DATA_BUFFER
> containing the information to the kernel. The kernel will update the
> paths of the file object, and will recall the NTFS driver to open the
> target (C:\Users).
>
> This REPARSE_DATA_BUFFER returned to the kernel is actually only a
> NTFS attribute ($REPARSE_POINT) stored along your file (C:\Documents
> and Settings), so this structure itself is directly "on-disk".
>
> Hence the fact I'm really skeptical of this undocumented structure.
>
> Sorry for the long mail, but I hope it will help you having a more
> concrete view of what mount point (and reparse points) are and aren't.
>
> Cheers,
>
> [3]: http://www.flexhex.com/docs/articles/hard-links.phtml
>
Your explanation is clear and detailed.
Now I do have a a more concrete view of what mount point (and reparse 
points) are and aren't.
Thank you very much for your share!

> - -- 
> Pierre Schweitzer <pierre at reactos.org>
> System & Network Administrator
> Senior Kernel Developer
> ReactOS Deutschland e.V.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVw3Q1AAoJEHVFVWw9WFsL2OoP/00hFA5QxUq38U5qYfZm9Of6
> ajhzIi7slzRkt0AiYyv8Pig3KWaZkylhd18zCrNJgeIuMBV4Qgh9SfTTLPx4uRpm
> /KobxAYaCMvryjc3v8+5nJbNdfUg126uB58lcHyjk6J7A62LAQJ053S1FtrPES1S
> FHgKPM1YEwjzjoPef5c0P1amzdYY5qQs6gihSzsKYYNOlv/YFAMgg4+p2BTkLnt0
> pY+OkScPSpb6b3h45t7NVRmH7B7V2mlzCpLnPZgiuUc6x182xY/OQ9PoctPfvpOf
> czIqUNuWFG8lMo/72pRm7lmfys4tbUeTTOnLXHpyZa4+CGHOXE39iH8PP5LMeR5R
> YythCLeM3Sb26a/ttF9jhaQA4N/hHb90qzAL6Dg4NneYWby/ggieuJqfQ8M5F/yV
> aIzUvNJvqeNxuD8ZszZkAnlC2jw55IsbvHcZxC+FCgIhGwpX+7bgadgYjtnn+596
> CSDfwg16Ba3hfzU9KFVp2YPFxHt5PVI0i3v9O81r/ugdTUfq9Pp72B/DGh50glka
> Ck/bsXcXF5mOKJL4FJ641JdpnutV+sh1gyH0YgftZ1+wlPcQhuu97IYRPlytug2W
> mOsRJWTK9QzuvSYifdJJfHnyWacDv5fiUyD+Nooxg9zabPHcy9R7jEr2ufwS6qUT
> wchnOr4lN+Jw8c5KbSre
> =0K8Y
> -----END PGP SIGNATURE-----