opening a file for writing and reading

Hello, I am trying to write a program which logs an IRC channel, and makes the log life available via HTTP. Currently I open the log file for writing in AppendMode, and keep it open, writing new lines as they come. I open the file for reading using withBinaryFile and ReadMode. Alas, I get the error, openBinaryFile: resource busy (file is locked). What is the proper work around for this? I could only open the file for writing when I actually have something to write, and then close it afterwards. But that still leaves a race condition if I try to write the file while it is being served or read the file while it is being updated. The read and writing are both done in the same application, but in different parts of the code. There is no way to share the file handle between the two parts. Thanks! - jeremy

On Mon, Jan 11, 2010 at 7:49 PM, Jeremy Shaw
Alas, I get the error, openBinaryFile: resource busy (file is locked).
What is the proper work around for this?
This behaviour is specified in the Haskell standard. I don't know what the rationale is intended to be, but I don't like the behaviour either. I believe you can work around it by using System.Posix.IO to open a file, then convert the Fd to a Handle.

On Mon, 2010-01-11 at 20:22 -0800, Bryan O'Sullivan wrote:
On Mon, Jan 11, 2010 at 7:49 PM, Jeremy Shaw
wrote: Alas, I get the error, openBinaryFile: resource busy (file is locked). What is the proper work around for this?
This behaviour is specified in the Haskell standard. I don't know what the rationale is intended to be, but I don't like the behaviour either.
I think in general it's to help you not shoot yourself in the foot by having one part of the code write over stuff you're in the middle of reading. In particular this would help for programs of the form $ ./prog foo -o foo where it ends up using the same file as both input and output. If this was what you actually intended to do then of course you can use the same single read/write file handle. There's also a specific case where it stops you shooting yourself in the foot. A file handle that you're using with hGetContents really should not change underneath you. That's why it gets put into the semi-closed state. But if you could have other open write handles to the same file then you can still shoot yourself in the foot and write weirdy non-deterministic programs.
I believe you can work around it by using System.Posix.IO to open a file, then convert the Fd to a Handle.
Right, you can bypass the safety mechanism that way. Duncan

On Jan 12, 2010, at 5:03 AM, Duncan Coutts wrote:
I believe you can work around it by using System.Posix.IO to open a file, then convert the Fd to a Handle.
Right, you can bypass the safety mechanism that way.
Opening as Fd works, but converting to a Handle causes the error to come back. Fortunately, it was easy to modify the code to just stick with Fd, and portability to Windows is not a concern. thanks everyone! - jeremy
participants (4)
-
Bryan O'Sullivan
-
Bulat Ziganshin
-
Duncan Coutts
-
Jeremy Shaw