(I hope creating new issues at bitbucket instead of the old Trac system is okay)
I've encountered http://whoosh.ca/ticket/70 (file lock fd not closed, that you fixed when importing whoosh into bitbucket -- this was the original point of my patch).
I'm opening a writer for each write in a FastCGI application (writes are not so frequent, but still, the system is exhausted of fds as the processes are reused).
Here's a small patch that tries to close the fd even if the flock fail. This also ensures the object state stays in sync (self.locked and self.fd). I'm silencing out eventual close errors not to mask the real exception raised until logging is available (I saw #6 here). I also fixed a missing self.locked update in the msvcrt case.
I do not have access to the box leaking fds on my side ATM but I should get a lsof or /proc/xxx/fd listing soon to ensure it's only the index not properly closed. Still, your fix might only fixes a part of #70 since the lsof output shows the fds of the opened segments (might only be the reporter's program indexing when lsof is launched, thus there is already no more leak).