on Windows, copyFile makes empty source and destination files when the source file is absent

[hsenag]

on Windows,

copyFile nonexistent shouldnotexist

succeeds and leaves 0-byte files for both nonexistent and shouldnotexist.

I would expect it to throw an exception and not create either source or destination file, which is what happens on Linux and MacOS.

The behaviour seems to have started in directory-1.3.8.0 and I bisected it to 78b3e59. I'm fairly sure it's directory because I did things
like holding Win32 and trying with a range of GHCs. With default versions we only noticed it starting with GHC 9.6, but I get the same
behaviour with GHC 9.4.8+Win32 2.13.3.0+directory 1.3.8.0 (for example).

I used this test program to track down where the problem started:

module Main where

import Control.Exception
import System.Directory
import System.IO.Error (isDoesNotExistError)

main :: IO ()
main = do
  removeFile "nonexistent.source" `catch` (\e -> if isDoesNotExistError e then return () else throwIO e)
  removeFile "shouldnotexist.target" `catch` (\e -> if isDoesNotExistError e then return () else throwIO e)
  (copyFile "nonexistent.source" "shouldnotexist.target" >> putStrLn "BAD: copyFile did not throw") `catch` (\e -> if isDoesNotExistError e then putStrLn "OK: copyFile threw" else throwIO e)
  doesFileExist "nonexistent.source" >>= \b -> if b then putStrLn "BAD: nonexistent.source exists" else putStrLn "OK: nonexistent.source does not exist"
  doesFileExist "shouldnotexist.target" >>= \b -> if b then putStrLn "BAD: shouldnotexist.target exists" else putStrLn "OK: shouldnotexist.target does not exist"
  removeFile "nonexistent.source" `catch` (\e -> if isDoesNotExistError e then return () else throwIO e)
  removeFile "shouldnotexist.target" `catch` (\e -> if isDoesNotExistError e then return () else throwIO e)
  return ()

ref: https://bugs.darcs.net/issue2721

[hasufell]

I can confirm. The relevant code is here:

directory/System/Directory/OsPath.hs

Lines 746 to 772 in a97a8a8

	-- | A helper function useful for replacing files in an atomic manner. The
	-- function creates a temporary file in the directory of the destination file,
	-- opens it, performs the main action with its handle, closes it, performs the
	-- post-action with its path, and finally replaces the destination file with
	-- the temporary file. If an error occurs during any step of this process,
	-- the temporary file is removed and the destination file remains untouched.
	withReplacementFile :: OsPath -- ^ Destination file
	-> (OsPath -> IO ()) -- ^ Post-action
	-> (Handle -> IO a) -- ^ Main action
	-> IO a
	withReplacementFile path postAction action =
	(`ioeAddLocation` "withReplacementFile") `modifyIOError` do
	mask $ \ restore -> do
	-- TODO: AFPP doesn't support openBinaryTempFile yet,
	-- so we have to use this (sad) workaround
	-- (on unix, converts using filesystem encoding, on windows
	-- converts with UTF-16LE)
	d <- decodeFS (takeDirectory path)
	(tmpFPath', hTmp) <- openBinaryTempFile d ".copyFile.tmp"
	tmpFPath <- encodeFS tmpFPath'
	(`onException` ignoreIOExceptions (removeFile tmpFPath)) $ do
	r <- (`onException` ignoreIOExceptions (hClose hTmp)) $ do
	restore (action hTmp)
	hClose hTmp
	restore (postAction tmpFPath)
	renameFile tmpFPath path
	pure r

[hasufell]

Fix is here: #178

However, I suggest @Rufflewind that we consider to use the package file-io for this in the future so that we can consolidate such low-level functionality. Having complicated Win32 code spread around different packages is problematic.

The openExistingFile function from that package does not suffer from this issue.

[Rufflewind]

Released: https://hackage.haskell.org/package/directory-1.3.8.5

[hasufell]

@bgamari do you have visibility which GHC versions ship with this bug?

[hsenag]

Thanks for the quick fix/release!

[Rufflewind]

This affects directory 1.3.8.0 through 1.3.8.4, which maps to GHC 9.6.1 through 9.10.1 according to https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history

[bgamari]

I have opened GHC#24843 to ensure that this bump is performed in future minor releases.

[andreasabel]

This affects directory 1.3.8.0 through 1.3.8.4,

Would be good to add this info in the release notes.