Re: [PATCH 1/2] include: Add ntifs.h with Reparse point related definitions and typedefs.(try 3)
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 think that it may be easier to get sys::tr2::_Stat implementation to wine without tests on reparse points. You can add this tests later but I'm not sure if they belong to msvcp tests. Thanks, Piotr
-----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? Furthermore, it looks highly suspicious even if undocumented, as a mount point is a standard reparse point in Windows, provided by Microsoft (IO_REPARSE_TAG_MOUNT_POINT), and thus, REPARSE_DATA_BUFFER is expected. [1]: /* Undocumented FSCTL_SET_REPARSE_POINT structure definition */ Cheers, - -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVw0qQAAoJEHVFVWw9WFsLCz8P/j4e8S0wbrXSWCgl0G2VCvED mPiqPFP1A9zhPAx2lyyhCFe1+s2GjKwOzfxx4CB9XIbrZgr27J6/COte8+pSCGL3 RvDMTiKZrFWHhlvn5GEep8A1uqqRVEq7QvyO1UlDQeCjZxOQq5JOgKJovRsqoan3 NCMQ8XgpiQxkEYuY7GgjQCWSF5bFJFGo7/jDX2zbI47VTc9I/bNJd5AhG1ZAY3Q7 6xpevQ4mVNkQ4tQ4981llZ6UoMs5QETu6HGIngCbDHQwRPF2eSfyT3dTUPi8dDAm lUv/c7rllQ1+O4gbfCUoKZIgk+YAOypixNNRVx/ft5Ln7Ly9+G18lVtIw2JFhcoX EobiYse/pyKsfdl6WsIGUH7Kp4wPn62WKms3aPPTFBFqPnuds3EjH0wEm+6pjOiK K0ZLsNPRAgPja57+tJ4ut0L0r1aBREXXFWmV0T8e2Tivk3SIBl2Gd7DO8UDf/+Mv TUudexL6qM+L5o/QuIXQ10pGSaasIWh2Hl6nQOvE1mq5AdV/jBWzaCOsIDqFmtZH X2v4gSD3tmX74luzm4QRBkFsx1IhzfBJB3DNfXw7dBwOmDAW/bUqHEPnvW/1WcFb Le47pE5Gt9ugOiMDi40tEtcQEmDkLBVR3vhoKtajnHedi9F+U3sEN7hqHYp0YoGp 5oESRKis8yQfHy3MUqeI =m9l1 -----END PGP SIGNATURE-----
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
-----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(a)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-----
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,
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(a)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-----
Hi, Piotr On 15/8/6 下午7:39, Piotr Caban wrote:
Hi,
I think that it may be easier to get sys::tr2::_Stat implementation to wine without tests on reparse points. You can add this tests later but I'm not sure if they belong to msvcp tests.
The reason of testing reparse points is to make sure the implementation has no relation with it, as I found BOOST handled reparse point in some functions. However, in my tests of other functions, tr2_functions regard them as regular files instead of handling them in implementation. So it has not necessary to test reparse points. Thank you for your help.
participants (3)
-
Pierre Schweitzer -
Piotr Caban -
YongHao Hu