NightOwl888 commented on code in PR #1138:
URL: https://github.com/apache/lucenenet/pull/1138#discussion_r1988627827
##########
src/Lucene.Net/Store/MMapDirectory.cs:
##########
@@ -314,7 +314,7 @@ internal virtual ByteBuffer[] Map(MMapIndexInput input,
FileStream fc, long offs
input.memoryMappedFile = MemoryMappedFile.CreateFromFile(
fileStream: fc,
mapName: null,
- capacity: length,
+ capacity: fc.Length, // use the full length of the file
Review Comment:
Reviewing this a bit more, the exception is almost certainly due to the
`RAMDirectory` "hole". Allowing `Share.Read` access in `Obtain()` means the
IOException that causes the lock to function will not occur. Without the
exception, `IsLocked()` can never return `true`. Since the lock file is just a
marker that indicates whether or not the directory is locked, using a fake one
for `RAMDirectory` should be fine.
So, we would need to change
https://github.com/apache/lucenenet/blob/54505e8964c112119b83adf8bf9163d687765cbe/src/Lucene.Net/Store/RAMDirectory.cs#L104
so there is a special case to create a fake lock file instead of copy it.
And remove the "hole" from
https://github.com/apache/lucenenet/blob/54505e8964c112119b83adf8bf9163d687765cbe/src/Lucene.Net/Store/NativeFSLockFactory.cs#L496-L498
so it is always using `Share.None`.
------------------------
Alternatively, we could change the `SharingNativeFSLock` to attempt to write
a byte in `IsLocked()`.
https://github.com/apache/lucenenet/blob/54505e8964c112119b83adf8bf9163d687765cbe/src/Lucene.Net/Store/NativeFSLockFactory.cs#L799-L802
This would cause an IOException when the file uses `Share.Read` since it
would not be writable, but it would be a different exception than
`NativeFSLockFactory.HRESULT_FILE_SHARE_VIOLATION`, so we would need to test
for both cases (and depending on the exception, we may need to store another
HResult value during initialization).
-----------------------
However, I still think that the best solution would be to change it to use
native methods. This would eliminate exceptions thrown just to check true/false
whether or not the directory is locked, since we could rely on native error
codes instead. After all, it is supposed to be a `NativeFSLockFactory`...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
