Forcefully set ioe_filename in IOException?

[Bodigrim]

I noticed in https://github.com/hasufell/file-io/actions/runs/7500925884/job/20420565223#step:5:295 that the exceptions seemingly do not set ioe_filename field of IOException. That's explainable: mkFD(which is responsible for this particular error) does not have a filename at hand.

A simple (crossplatform!) reproducer is this:

$ cabal repl -b file-io
ghci> :set -XQuasiQuotes
ghci> x = System.File.OsPath.openFile [System.OsPath.osp|foo|] WriteMode
ghci> y = System.File.OsPath.openFile [System.OsPath.osp|foo|] WriteMode
ghci> x
{handle: <file descriptor: 14>}
ghci> y
*** Exception: openFile: resource busy (file is locked)

It would be painful to debug such write lock in a real-life application, because the error message does not mention which filename is locked.

Could functions in file-io catch and re-throw IOExceptions, forcefully setting ioe_filename if empty?

[Bodigrim]

Essentially I'm asking to do what base does in such cases:

openFile :: FilePath -> IOMode -> IO Handle
openFile fp im = 
  catchException
    (openFile' fp im dEFAULT_OPEN_IN_BINARY_MODE True)
    (\e -> ioError (addFilePathToIOError "openFile" fp e))

It catches the underlying IO exception and rethrows it, forcefully setting ioe_filename via addFilePathToIOError.

[hasufell]

Yes, we should try to mimick base as much as possible.