-----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.:)
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@reactos.org System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.