Data.ByteStirng.Lazy.hGetContents doesn't unlock i-node

[guest]

I found that Data.ByteStirng?.Lazy.hGetContents doesn't unlock i-node even after retreiving whole contents. Because of this and the fact that file locking mechanism of GHC uses i-node, sometimes it causes a problem whose cause is hard to find.

See this example assuming file 'a' already exists:

testB = forM [1..] $ \_ -> do
    r <- B.readFile "a" >>= \r -> return $! B.length r `seq` r
    B.writeFile "b" (B8.pack "abc")
    renameFile "b" "a"

When I run this test on GHCi, it shows this error:

*Main> testB *** Exception: b: openBinaryFile: resource busy (file is locked)

I presume that this error happened because:

1. readFile locks the i-node of 'a' and continues to lock after reading whole contents
2. writeFile writes contents to 'b'
3. Maybe GC runs and closes the handle but doesn't unlock i-node
4. renaming 'b' to 'a' causes free the i-node of 'a'
5. readFile locks another i-node of 'a'
6. writeFile reuses the first i-node of 'a' which is still locked

It is very difficult to find that readFile causes a problem, because an error occures in writeFile.

I'm not sure this is a problem of ByteString? or GC, but this problem doesn't occur when I use System.IO.hGetContents because it closes the handle and unlocks the i-node after retrieving whole contents.

[dons]

I'm not sure how we missed this, but yes, the lazy bytestring lazy IO operations weren't finalizing the resource once EOF was encountered. I've pushed a patch to fix this, and your test programs now work.

Can you confirm that with the latest darcs repository, your code now works?

darcs get  http://darcs.haskell.org/bytestring

[guest]

Yes, I confirmed that our code worked fine with the latest repository. Thank you.