I can’t figure out under what circumstances FsRtlProcessFileLock returns
STATUS_PENDING. It’s for an IRP_MN_LOCK type call (and almost always for
desktop.ini). This isn’t a documented return code for this function call…
any ideas?
TIA
It means the lock has not yet been granted - it’s pending. The caller
did not indicate “fail immediately” behavior, so we’re returning control
back to them. They can then go do other things while the lock operation
blocks and waits for the lock to become available.
STATUS_PENDING may not be documented, but it fits the general I/O
architecture of Windows.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Thanks for the quick response Tony!
“Tony Mason” wrote in message news:xxxxx@ntfsd…
It means the lock has not yet been granted - it’s pending. The caller
did not indicate “fail immediately” behavior, so we’re returning control
back to them. They can then go do other things while the lock operation
blocks and waits for the lock to become available.
STATUS_PENDING may not be documented, but it fits the general I/O
architecture of Windows.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
How can I tell what it’s waiting for?
If I could tell what it is waiting for, should I complete the IRP at that
point with some appropriate status, or will the system eventually get around
to it? It seems like I shouldn’t touch the IRP after this call.no matter
what the return code is…
Or, how do I turn on the “Fail Immediately” behavior?
Thanks again…
“Tony Mason” wrote in message news:xxxxx@ntfsd…
It means the lock has not yet been granted - it’s pending. The caller
did not indicate “fail immediately” behavior, so we’re returning control
back to them. They can then go do other things while the lock operation
blocks and waits for the lock to become available.
STATUS_PENDING may not be documented, but it fits the general I/O
architecture of Windows.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
It is waiting for the lock to become available (e.g., this is a lock
conflict, and the IRP is hanging until the lock can be granted.)
And you are right, you can’t touch the IRP after you get back
STATUS_PENDING. When the lock can be granted, the package will complete
the IRP.
If you want fail immediately semantics, set the SL_FAIL_IMMEDIATELY in
the I/O Stack Location. If you are doing this via the NtLockFile API,
set the “FailImmediately” option to TRUE. If you are using some layered
glop on top of NtLockFile then you’ll have to figure out how they’ve
translated this option - while I know how the OS works, application
programming is far too difficult for the likes of me.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
I now set the SL_FAIL_IMMEDIATELY flag and it’s working the way I expected.
Thanks for the excellent (as usual) explanation, Tony. I did notice though
that fastfat does not
need to set this flag - so I must have some other logic problem I’m unaware
of that is holding
this lock too long, or something. Now I’m onto that path, to try to figure
that out.
GAP
“Tony Mason” wrote in message news:xxxxx@ntfsd…
It is waiting for the lock to become available (e.g., this is a lock
conflict, and the IRP is hanging until the lock can be granted.)
And you are right, you can’t touch the IRP after you get back
STATUS_PENDING. When the lock can be granted, the package will complete
the IRP.
If you want fail immediately semantics, set the SL_FAIL_IMMEDIATELY in
the I/O Stack Location. If you are doing this via the NtLockFile API,
set the “FailImmediately” option to TRUE. If you are using some layered
glop on top of NtLockFile then you’ll have to figure out how they’ve
translated this option - while I know how the OS works, application
programming is far too difficult for the likes of me.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com