However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess.
close_fds :: Bool
Close all file descriptors except stdin, stdout and stderr in the new process
This refers to inheriting open unix file descriptors (or Win32 HANDLEs) in the child process. It's not the same as closing the Haskell98 Handles in the parent process that you pass to the child process.
So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour.
The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know.
One guiding principle of resource management is that whoever opens/allocates something should release/free it. i.e. if you did the malloc you do the free. For that reason it seems weird that I call openFile but someone else calls hClose on my behalf.
Plus, in my particular application, the above behaviour is necessary or I'm going to have to write to a file, open that file, and copy it over to my intended file (which is what I will end up doing, no doubt!)
I don't remember exactly why it's done this way, but it might have something to do with trying to maintain the (possibly ill-conceived) Haskell98 file-locking principle. System.Posix.handleToFd also closes the Handle, FWIW.
There's nothing stopping you from re-opening the file and seeking to the end, as a workaround.
"openFile file AppendMode" is how I ended up doing it, which saves writing a seek in there. It works just fine, merely at the cost of closing/opening handles more than necessary.
I could probably be convinced without much difficulty that we should stop closing these Handles; however I do have a vague feeling that I'm forgetting something!
Documenting it more clearly would be helpful. As for changing the behaviour - while I think the other way round would be much better, it brings up loads of reverse compatibility headaches, so I'm not sure its worth it. Thanks Neil