Pierre Schweitzer
0b713d4fa0
[NTOSKRNL] On open, verify and validate the hint device object if any
2018-10-05 10:49:59 +02:00
Pierre Schweitzer
779d87b483
[NTOSKRNL] Implement IopCheckTopDeviceHint()
2018-10-05 10:49:59 +02:00
Pierre Schweitzer
2a182931b6
[NTOSKRNL] A bit of cleanup in Io*FilterContext()
2018-10-04 22:24:52 +02:00
Pierre Schweitzer
5f0d02eb52
[NTOSKRNL] Implement IoChangeFileObjectFilterContext()
2018-10-04 19:30:39 +02:00
Pierre Schweitzer
a43fb5e054
[NTOSKRNL] Implement IoGetFileObjectFilterContext()
2018-10-04 19:30:38 +02:00
Pierre Schweitzer
d8f22735ed
[NTOSKRNL] In IopQueryNameInternal(), enclose output copy in a SEH statement
2018-10-03 22:55:23 +02:00
Pierre Schweitzer
520f404e9c
[NTOSKRNL] In IoQueryFileDosDeviceName(), in case of an error, return appropriate status
2018-10-03 17:08:42 +02:00
Pierre Schweitzer
8c6c5a92e8
[NTOSKRNL] Implement DOS name query in IopQueryNameInternal()
2018-10-03 13:56:18 +02:00
Pierre Schweitzer
769157f6ff
[NTOSKRNL] Allow FileNameInformation not to be implemented in storage stack
2018-10-03 13:52:05 +02:00
Pierre Schweitzer
46bda8a4c6
[NTOSKRNL] In IopQueryNameInternal() don't copy name if it's not valid
2018-10-03 13:50:16 +02:00
Pierre Schweitzer
4a7e89770e
[NTOSKRNL] Implement IoQueryFileDosDeviceName()
2018-10-03 11:56:21 +02:00
Pierre Schweitzer
abfddca8bb
[NTOSKRNL] Stub support for querying DOS name when parsing FO name
2018-10-03 11:45:08 +02:00
Pierre Schweitzer
a1401a7577
[NTOSKRNL] Use faster internal helper to query name
...
This only applies if we're called from kernel mode
with a synchronous file.
2018-10-03 10:22:33 +02:00
Pierre Schweitzer
1348f62f20
[NTOSKRNL] Rename IopQueryNameFile to IopQueryNameInternal
2018-10-03 10:22:33 +02:00
Thomas Faber
8fbc488050
[NTOS:IO] Implement IopAcquireFileObjectLock and use it to fix IopLockFileObject
2018-10-02 09:56:55 +02:00
Pierre Schweitzer
890a293683
[NTOSKRNL] Fix remaining access computation on open
2018-09-30 10:55:44 +02:00
Pierre Schweitzer
6d0c07c44f
[NTOSKRNL] Implement access check for secure open
2018-09-30 10:55:43 +02:00
Pierre Schweitzer
cf25432eed
[NTOSKRNL] Don't lock file object on close if we're not called by Ob
...
IopCloseFile can be called by IopDeleteFile. In that situation, it
doesn't set any process as first parameter. Furthermore, we are in a
situation where it's not required to lock the file object (see the
assert before the call).
2018-09-29 16:25:58 +02:00
Pierre Schweitzer
207ff9444e
[NTOSKRNL] Reference the file object before issuing the unlock all IRP
...
This fixes the last kmode assert triggered by httpd on ReactOS.
CORE-12045
2018-09-29 11:22:22 +02:00
Pierre Schweitzer
5472c1db82
[NTOSKRNL] Unlock file if required on last process handle close
2018-09-28 23:34:28 +02:00
Timo Kreuzer
ca9fd861aa
[DRIVERS][NTOS][NDK] Use IO_STACK_LOCATION instead of EXTENDED_IO_STACK_LOCATION and remove the latter from NDK
2018-07-01 14:45:21 +02:00
Pierre Schweitzer
fc5a61d8b7
[NTOSKRNL] Revert 4ef0887: experiments show that our FastFAT is not ready yet to live on its own.
...
So, bring back the infamous IopParseDevice() hack. Dismounting is to be fixed in FastFAT.
Even though it might not be the last remaining bug...
CORE-14124
CORE-14126
CORE-14133
2017-12-25 11:24:13 +01:00
Pierre Schweitzer
4ef08871ee
[NTOSKRNL] Make again an attempt at killing the IopParseDevice() hack.
...
For the record, the only place it was remaining was 1st stage, notably because
FSD (FastAT <3) was missing a few features. As this features weren't triggered
in 3rd stage (unless forced), it was not needed there any longer.
Now that they are implemented, and seem working out of the box, this hack might
not be longer anymore.
This is my ... ?! pfff attempt at killing it. It might not be the last, so just
disabling the hack for now. If there are no regressions (who can really believe that?)
we'll be clear for dropping it once for all.
2017-12-17 23:30:58 +01:00
Colin Finck
c2c66aff7d
Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers into modules, and delete rossubsys.
2017-10-03 07:45:34 +00:00