-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by YongHao HuHi,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Post by Piotr CabanHi,
+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
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 <***@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