Bugfix for IRP_MJ_SET_INFORMATION/FileEndOfFileInformation: really set the information. The test still works fine in Windows and still fails hard in ReactOS.
svn path=/trunk/; revision=73200
Add tests for the NtCreateSection functions which mimic some of the behavior that can be exposed by FSDs (late init, too small files, and so on).
It was designed in W2K3.
svn path=/trunk/; revision=73198
- accesschk.c: Remove redundant SepAccessCheck/SepAccessCheckEx pair of private functions; instead just rename SepAccessCheckEx into SepAccessCheck and use it directly in the code. NOTE: SepAccessCheck is *incomplete* (in particular it doesn't retrieve the information needed to initialize the 'Privileges' parameter).
- sid.c: Comments formatting fix.
- token.c:
* Finish to implement SeQueryInformationToken . This function is really the same as NtQueryInformationToken but without all the stuff needed for user-mode buffer access protection.
* Some code simplifications in NtQueryInformationToken.
I need this to fix a "FIXME: Use SeQueryInformationToken" in some code I'm also fixing (& commit later).
[NDK]: Fix parameter types and add annotations to RtlCopySidAndAttributesArray.
[KMTESTS:NTOS_SE]
- Reenable the 'SeQueryInfoToken' test.
- Show that SeQueryInformationToken doesn't support 4 token information classes, which are supported only by NtQueryInformationToken.
- Fix calling of SeAccessCheck. In particular the 'Privileges' parameter is not allocated by the caller, but instead is allocated by SeAccessCheck *and* returned to the caller (who then must free the buffer using SeFreePrivileges). This fixes the encountered BSODs that leaded to disabling preventively the test in r59178.
- Minor code cleaning.
svn path=/trunk/; revision=73122
Add a stress test for tunnel cache implementation, where we have fun adding duplicated entries.
It doesn't seem to go well.
These tests are also known as "Learn your English ordinals", or as "Learn how to count in English". My pleasure.
CORE-11819
svn path=/trunk/; revision=72192
New test case which is matching the MS FastFAT CcCopyRead (minus the offset) and shows clearly the issue in our Cc.
It also shows that my hack is utterly broken :-).
CORE-11003
CORE-11819
svn path=/trunk/; revision=72182
Modify a bit the read test so that it actually fails in ReactOS. It instructs us that when it comes to file boundaries, our Cc fails to properly align read (whereas it should!).
This is the behavior exposed by the MS FastFAT.
CORE-11003
CORE-11819
svn path=/trunk/; revision=72169
Complete the tests for Cc: not only check for alignment, but also check that expected data are returned.
Thanks to Thomas for his help on this :-).
CORE-11003
svn path=/trunk/; revision=72165
Introduce tests for Cc :-)
Currently, we only test CcCopyRead for specific alignment matters. It shows that under certain conditions, our Cc doesn't align reads it does, leading to later failure in disk.sys.
This reproduces an error observed with MS FastFAT in ReactOS.
CORE-11003
svn path=/trunk/; revision=71445
- Use the calling thread instead of the passed-in thread to validate APC status in ExReleaseResourceForThreadLite. The latter can be user-set and might not be a KTHREAD at all.
CORE-11315 #resolve
svn path=/trunk/; revision=71398
Add more failing tests for MCB. These are pretty basics and deal with holes.
They are pretty handy to show how broken the current MCB implementation is, in regard to holes management: it fails at properly counting runs when there are holes and it creates virtual runs (hence the broken count) for each hole. This shouldn't happen.
CORE-11002
svn path=/trunk/; revision=71177
Add a simple test for FsRtlAddLargeMcbEntry() which shows how hard it's broken... Not only it doesn't support mismatching LBNs, but it also replaces current mapping with broken one
CORE-11002
svn path=/trunk/; revision=71141
Add more tests for LargeMcb functions.
These are not invented but real cases: they are extracted from Ext2Fsd driver attempting to read a file from disk. The read file in ReactOS is totally corrupted.
This shows how broken our current MCB implementation is. And unfortunately confirms CORE-11002.
I recommend not to import any other FSDs relying on MCB as long as this is not fixed (eg. CORE-11040); it makes them pretty pointless.
CORE-11002
svn path=/trunk/; revision=71091
- Define a new macro function KmtGetSystemOrEmbeddedRoutineAddress() which is to be used to get a function address from Mm if it exists system-wide or to fallback to embedded function if it doesn't exist
- Use this mechanism to add tests for the newly implemented FsRtlRemoveDotsFromPath() which is Vista+.
That allows, with a single build (and thus, same binaries), testing a function in ReactOS and in Windows.
svn path=/trunk/; revision=71046
- 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
- Pass the correct DeviceObject to PoRequestPowerIrp's callback
- Use the IRP stack to store callback parameters instead of a pool allocation as shown by the test
svn path=/trunk/; revision=69503
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
