- Add a test verifying that opening a file using different parent directories still yields handles to the same file
CORE-10483
svn path=/trunk/; revision=69877
Add more tests for IoCreateFile(), this time purely dealing with symlinks reparse points.
They won't run on ReactOS (obviously) as we don't have RW NTFS support.
On Windows, they show interesting results....
With Windows 2003, creating the symlink is allowed and works, but then Windows is totally unable to deal with it and keeps complaining about an unhandled reparse tag.
The only way to open it is to open the reparse point itself. Not that working symlinks... Not sure which part is not able to handle the said reparse tag. NTFS? Io?
With Windows Vista+, it just works fine. Symlink is created & functionnal.
Broken logic!
svn path=/trunk/; revision=69353
- Properly free handles in driver (spotted by Thomas)
- Remove dead code in driver (spotted by Thomas)
- Send an IOCTL to stop on symlinks to allow more precise tests
svn path=/trunk/; revision=69336
Extend the IoCreateFile tests with two parts tests.
First part properly checks for opening/reparse handling on mount points (and ideally on symlinks, see below).
The other part checks for proper handling of the IO_STOP_ON_SYMLINK parameter.
Regarding symlink, I'm clearly not convinced that what I did is correct (hence the failure on both W2K3 & ROS). It seems to me that symlink resolution is up to the FSD and not to IO which only handles mount point traversal.
If someone (Alex?) can confirm/infirm and give more insight, that's more than welcome.
svn path=/trunk/; revision=69322
- Add missing OBJ_KERNEL_HANDLE
- OBJ_KERNEL_HANDLE in user mode has no effect... no reason to make a define around it
CORE-10207
svn path=/trunk/; revision=69296
Revert the DDK compatibility hack and apply a real fix. I kept the hack for NDK exports, we should consider changing them as well for consistency reasons.
svn path=/trunk/; revision=63268
Add a temp hack that allows to compile kmtest_drv with either the current incompatible object type data imports or with the fixed ones
svn path=/trunk/; revision=63222
Complete a bit more IoCreateFile tests, taking into account relatives.
A side note (related to first commit - actually to these test as a whole):
It's pretty unfortunate that they work (on my Windows 2K3). They just expose
a totally different behavior than expected reading R. Nagar (pp 478 - 479).
The experimental behavior also being different from behavior expected from IFS
samples provided by MS.
Perhaps some magic in the callpath between IopParseDevice return and IoCreateFile return?
svn path=/trunk/; revision=62960
- Disable IoRegisterDeviceInterface test, since it crashes on Windows
- Add test showing that IoRegisterPlugPlayNotification's callback receives the full path to the symbolic link (this was fixed in r62249)
svn path=/trunk/; revision=62553
No need now to declare a NTSTATUS ExceptionStatus; variable to be able to use KmtStartSeh() / KmtEndSeh() macros; this is done automagically.
svn path=/trunk/; revision=60320
