openFile gives "file is locked" error on Linux when creating a non-existing file

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Oct 8 06:20:04 UTC 2024


On Tue, Oct 08, 2024 at 11:23:14AM +0530, Harendra Kumar wrote:

> This cannot be a TOCTOU bug as the code to check the existence of the
> file is only introduced for debugging this issue, to report in case
> the file exists for some reason.  Our understanding is that this file
> cannot exist in the first place. We have never seen the "File exists"
> message being printed, I will make that an error to make sure. The
> tests create a temporary file using a random directory name in the
> system temp directory, the directory is destroyed at the end of the
> test. Also, tests do not run in parallel, we are using hspec to run
> tests and it does not run tests in parallel unless we explicitly say
> so, so there is no possibility that two tests could be trying to use
> the same file. We will double check that. Also, this happens only on
> Linux. We will also try the append mode as you suggested.

What sort of filesystem is "/tmp/fsevent_dir-.../watch-root" located in?

Creating and closing a file in write mode from GHC:

    import System.IO

    main :: IO ()
    main = do
        putStrLn "Show time" >> hFlush stdout
        openFile "/tmp/foo.out" WriteMode >>= hClose

translates on Linux to (strace):

    write(1, "Show time\n", 10)             = 10
    openat(AT_FDCWD, "/tmp/foo.out", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 6
    newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
    ftruncate(6, 0)                         = 0
    ioctl(6, TCGETS, 0x7ffd358412a0)        = -1 ENOTTY (Inappropriate ioctl for device)
    close(6)                                = 0

Nothing at all unusual happening here, so if the OS returns EBUSY,
perhaps there's something interesting you can report about the state of
that directory before file creation?  Perhaps there's some filesystem or
other kernel resource you're maxing out during the tests?

-- 
    Viktor.


More information about the ghc-devs mailing list