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

[Pierre Schweitzer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/06/2015 04:12 PM, YongHao Hu wrote:
> Hi,
> 
> On 15/8/6 下午7:52, Pierre Schweitzer wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Hi,
>> 
>> On 06/08/2015 13:39, Piotr Caban wrote:
>>> Hi,
>>> 
>>> On 08/05/15 07:45, YongHao Hu wrote:
>>>> +typedef struct _REPARSE_MOUNTPOINT_DATA_BUFFER +{ +
>>>> DWORD ReparseTag; +    DWORD ReparseDataLength; +    WORD
>>>> Reserved; + WORD ReparseTargetLength; +    WORD
>>>> ReparseTargetMaximumLength; + WORD Reserved1; +    WCHAR
>>>> ReparseTarget[1]; +} REPARSE_MOUNTPOINT_DATA_BUFFER, 
>>>> *PREPARSE_MOUNTPOINT_DATA_BUFFER;
>>> This structure is not defined in native ntifs.h. I don't know
>>> if it's acceptable to add it in wine.
>> I'd say, no, it's not. For the sole reason that the structure
>> defined upper is wrong and doesn't match reality. Offsets are
>> wrong and data are missing.
>> 
>> Reading the comment[1], you wrote on top of the definition in
>> the source file you provided, I wonder: What kind of undocumented
>> things are you referring to? FSCTL_SET_REPARSE_POINT is
>> documented and taking either REPARSE_DATA_BUFFER or
>> REPARSE_GUID_DATA_BUFFER. Would you have details about the
>> missing structure? Would you have test cases? Real applications
>> that use it?
> Sry, I did not test this seriously and have no idea whether it was
> right or not.  I do not understand reparse point clearly. I found
> FSCTL_SET_REPARSE_POINT on some open source projects[1][2] when I
> want to create and test reparse points in tr2_functions. Thank you
> very much.:)
> 
> 
> [1]: http://osxr.org/qt/source/qtbase/tests/shared/filesystem.h
> line 106 [2]:
> http://markcox.googlecode.com/svn-history/r37/trunk/tools/reparse.h
>
> 
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.

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

- -- 
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-----