Skip to content

Add FileShare.Delete to SimpleFSDirectory and FSIndexOutput, #1283 - #1344

Merged
paulirwin merged 1 commit into
apache:masterfrom
paulirwin:issue/1283
Jun 13, 2026
Merged

Add FileShare.Delete to SimpleFSDirectory and FSIndexOutput, #1283#1344
paulirwin merged 1 commit into
apache:masterfrom
paulirwin:issue/1283

Conversation

@paulirwin

Copy link
Copy Markdown
Contributor
  • You've read the Contributor Guide and Code of Conduct.
  • You've included unit or integration tests for your change, where applicable.
  • You've included inline docs for your change, where applicable.
  • There's an open issue for the PR that you are making. If you'd like to propose a change, please open an issue to discuss the change or find an existing issue.

Add FileShare.Delete to SimpleFSDirectory and FSIndexOutput

Fixes #1283

Description

SimpleFSDirectory opened its read handles with FileShare.ReadWrite, diverging from NIOFSDirectory (ReadWrite | Delete). On Windows this caused File.Delete to throw a sharing violation while a reader held the file open; IndexFileDeleter swallows that and defers the delete to a retry list, so superseded index files accumulate on disk for the lifetime of a long-lived reader.

Add FileShare.Delete to both SimpleFSDirectory read handles and to the shared FSIndexOutput write handle (used by all FSDirectory subclasses) so that every handle Lucene.NET opens on a file permits deletion. Windows requires all open handles to allow Delete share for a delete to succeed, making the guarantee unconditional and matching the POSIX delete-while-open semantics that IndexFileDeleter already assumes.

This is a deliberate divergence from upstream Java, whose RandomAccessFile (used by SimpleFS for both read and write) omits FILE_SHARE_DELETE on Windows; only FileChannel (NIOFS/MMap) includes it. MMapDirectory's read handle is addressed separately in #1267.

Adds Windows-gated regression tests in TestDirectory that confirm a delete succeeds while a read or write handle is open (and that the still-open read handle keeps returning the original bytes).

… path (apache#1283)

SimpleFSDirectory opened its read handles with FileShare.ReadWrite, diverging
from NIOFSDirectory (ReadWrite | Delete). On Windows this caused File.Delete to
throw a sharing violation while a reader held the file open; IndexFileDeleter
swallows that and defers the delete to a retry list, so superseded index files
accumulate on disk for the lifetime of a long-lived reader.

Add FileShare.Delete to both SimpleFSDirectory read handles and to the shared
FSIndexOutput write handle (used by all FSDirectory subclasses) so that every
handle Lucene.NET opens on a file permits deletion. Windows requires all open
handles to allow Delete share for a delete to succeed, making the guarantee
unconditional and matching the POSIX delete-while-open semantics that
IndexFileDeleter already assumes.

This is a deliberate divergence from upstream Java, whose RandomAccessFile (used
by SimpleFS for both read and write) omits FILE_SHARE_DELETE on Windows; only
FileChannel (NIOFS/MMap) includes it. MMapDirectory's read handle is addressed
separately in apache#1267.

Adds Windows-gated regression tests in TestDirectory that confirm a delete
succeeds while a read or write handle is open (and that the still-open read
handle keeps returning the original bytes).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@paulirwin
paulirwin requested a review from NightOwl888 June 12, 2026 22:27
@paulirwin paulirwin added the notes:bug-fix Contains a fix for a bug label Jun 12, 2026
@paulirwin
paulirwin merged commit e2e5d97 into apache:master Jun 13, 2026
211 checks passed
@paulirwin
paulirwin deleted the issue/1283 branch June 13, 2026 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

notes:bug-fix Contains a fix for a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add Delete file share mode to SimpleFSDirectory and FSIndexOutput for Windows support

2 participants