[Hugs-bugs] File remains locked after crash
Hi, On Windows, Hugs CVS Head: Change to a directory and run, at the prompt: writeFile "test.txt" (error "fail") The file test.txt is created, and the error "fail" is given. Now flipping to Windows explorer, try to delete the file test.txt and you can't because its still held open by hugs. The only way I can find for Hugs to release the file is to close hugs and restart it. My guess is that the handle that is openned by writeFile is not closed on error. For reference, GHCi has the same problem, but much worse. While GHCi locks the handle opened by writeFile, it also locks the file in this circumstance: readFile "ans2.txt" >> putStrLn (error "fail") While Hugs doesn't (or at least allows the file to be deleted) Thanks Neil
On Mon, May 01, 2006 at 04:32:30PM +0100, Neil Mitchell wrote:
On Windows, Hugs CVS Head:
Change to a directory and run, at the prompt: writeFile "test.txt" (error "fail")
The file test.txt is created, and the error "fail" is given.
Now flipping to Windows explorer, try to delete the file test.txt and you can't because its still held open by hugs. The only way I can find for Hugs to release the file is to close hugs and restart it.
My guess is that the handle that is openned by writeFile is not closed on error.
This should be a better implementation of writeFile: import Control.Exception import System.IO writeFile' :: FilePath -> String -> IO () writeFile' f txt = bracket (openFile f WriteMode) hClose (flip hPutStr txt)
Hi,
This should be a better implementation of writeFile:
import Control.Exception import System.IO
writeFile' :: FilePath -> String -> IO () writeFile' f txt = bracket (openFile f WriteMode) hClose (flip hPutStr txt)
Yes, it works better in the error case, so is definately preferable. Is there any reason why this isn't the standard definition of writeFile? Especially in an interactive environment likes Hugs/GHCi. The problem still remains however with the following command: writeFile' "test4.txt" (show $ last [1..]) Which is non-terminating therefore requires the user to break the program with Ctrl-C. When the user presses Ctrl-C the bracket is not run, so the file remains locked afterwards. Thanks Neil
participants (2)
-
Neil Mitchell -
Ross Paterson