According to the LockFileEx() documentation, a file offset is specified in lpOverlapped->Offset/OffsetHigh. But when debugging winword.exe to analyze its file system behaviors, I see it calls LockFileEx() on a 122-byte file with Offset=0xfffffffb and OffsetHigh=0xffffffff, and the call completes successfully. Apparently this is not a valid offset, what does this mean?
Asked
Active
Viewed 135 times
-1
Remy Lebeau
- 555,201
- 31
- 458
- 770
herb
- 139
- 8
-
I seriously doubt that WinWord would call `LockFileEx` with such an offset (`0xfffffffffffffffb` is `-5` if treated as a signed value, `18446744073709551611` as an `unsigned` value). I would suspect a flaw in your debugging before I suspect a flaw in WinWord. – Remy Lebeau Oct 06 '20 at 17:36
-
now i suspect that -5 is 5 bytes back from end of file – herb Oct 07 '20 at 02:01
-
that would make sense for a seek, but not a lock – Remy Lebeau Oct 07 '20 at 02:22
-
I create a sample and test the `LockFileEx` function but it does not work as you say, can you provide reproducible code snippets so that we can find the problem. – Zeus Oct 07 '20 at 05:54
1 Answers
1
From MSDN:
Locking a region that goes beyond the current end-of-file position is not an error.
They could be using the lock as some kind of flag or for synchronization.
Anders
- 97,548
- 12
- 110
- 164