Documentation for doesFileExist lies

[andreasabel]

directory/System/Directory.hs

Lines 1271 to 1279 in b33c108

	{- |The operation 'doesFileExist' returns 'True'
	if the argument file exists and is not a directory, and 'False' otherwise.
	-}
	doesFileExist :: FilePath -> IO Bool
	doesFileExist path = do
	(not <$> pathIsDirectory path)
	`catchIOError` \ _ ->
	pure False

The operation 'doesFileExist' returns 'True' if the argument file exists and is not a directory, and 'False' otherwise.

This is wrong for symlinks, which are not directories, but still get False.

Relying on the documentation leads to this bug sequence:

• Symlink treated as directory ndmitchell/filepattern#5
• Symlink treated as directory agda/fix-whitespace#9

More true would be "not a directory and not a symlink". However, I don't know whether this is the whole story yet. The semantics of doesFileExist should be secured by a testsuite.

[Rufflewind]

More true would be "not a directory and not a symlink". However, I don't know whether this is the whole story yet.

For historical reasons, symbolic links are transparent to all the doesWhateverExist functions. In other words, those functions always dereference the symbolic link(s) and return the attributes of the destination. Consequently, doesFileExist can return either True or False, depending on circumstances.

Will add a note to clarify this in the docs and update the tests. Long-term, there is need for a cleaner API around file metadata attributes: #143

[andreasabel]

Thanks for the fix.

I realized that my test setup was flawed:

$ mkdir dir
$ mkdir dir/a
$ mkdir dir/b
$ touch dir/a/file
$ ln -s dir/a/file dir/b/file
$ tree
.
└── dir
    ├── a
    │   └── file
    └── b
        └── file -> dir/a/file
$ ghci
ghci> :m + System.Directory
ghci> doesFileExist "dir/b/file"
False

The answer of doesFileExist is correct. I was fooled by an unexpected behavior by the BSD/macOS ln command;

$ ln -s dir/a/file dir/b/file

I would have expected that this creates inside dir/b a link file -> ../a/file to the existing file dir/a/file, rather than literally placing the string dir/a/file into the link.
So, I would have expected ln to satisfy this specification: After ln -s src dest, if src exists, then dest points to src.
(But wtf did they implement??)

So, apologies for the false attribution. And thanks for the clarification in the docs and the testcase!

[Rufflewind]

rather than literally placing the string dir/a/file into the link.

Symbolic links are in fact just a "file with a string in it". The string is not interpreted when it is created, but only when the link is read. To create the link you intended, there's a couple different ways, depending on what kind of link you want:

# Create a RELATIVE link
ln -s ../../dir/a/file dir/b/file
ln -s -r dir/a/file dir/b/file               # GNU-only (Linux-like OSes)

# Create an ABSOLUTE LINK
ln -s "$PWD/dir/a/file" dir/b/file           # Doesn't dereference symlinks in source
ln -s "$(realpath dir/a/file)" dir/b/file    # Dereferences symlinks in source

[andreasabel]

ln -s -r dir/a/file dir/b/file

I think this is what I expected to be default for the "relative" case...
Thanks for enlightening me!