canonicalizePath behaves strangely with paths that do not exist
The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.
This is complicated by differing behaviors of the underlying realpath(char*, char*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:
- $HOME/tmp/foo is a file.
- $HOME/tmp/bar is a directory.
- $HOME/tmp/baz does not exist.
Linux:
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/foo/subdir"
"/home/creswick/tmp/foo"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/bar/subdir"
"/home/creswick/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/baz/subdir"
"/home/creswick/tmp/baz"
OS-X:
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/foo/subdir"
"/Users/hudson/tmp/foo/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/bar/subdir"
"/Users/hudson/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/baz/subdir"
"/Users/hudson/tmp/baz"
Trac metadata
Trac field | Value |
---|---|
Version | 6.12.3 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/directory |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |