[darcs-users] darcs patch: Make FileName.drop_dotdot work with abso... (and 3 more)

David Roundy droundy at darcs.net
Fri Sep 26 14:11:09 UTC 2008


On Thu, Sep 25, 2008 at 12:42:49PM -0700, Dmitry Kurochkin wrote:
> Thu Sep 25 21:57:11 MSD 2008  Dmitry Kurochkin <dmitry.kurochkin at gmail.com>
>   * Make FileName.drop_dotdot work with absolute paths.
> 
> Thu Sep 25 21:57:26 MSD 2008  Dmitry Kurochkin <dmitry.kurochkin at gmail.com>
>   * Resolve issue1078: make ioAbsolute work with symbolic links in file paths.
> 
> Thu Sep 25 22:01:03 MSD 2008  Dmitry Kurochkin <dmitry.kurochkin at gmail.com>
>   * Move issue1078 test from bugs to tests.
> 
> Thu Sep 25 23:39:53 MSD 2008  Dmitry Kurochkin <dmitry.kurochkin at gmail.com>
>   * Rewrite ioAbsolute using System.Directory.canonicalizePath.

I got around to reading the code for canonicalizePath, and it turns
out to correspond to an OS function on Windows that doesn't seem to do
what we want at all.  Rejected.  And in the future, if you'd avoid
using undocumented library functions, I wouldn't have had to go to the
trouble of reading Microsoft documentation.

For the curious, it seems from the documentation that using
canonicalizePath will cause a regression in precisely issue1078 on
windows.  If not, then we're relying on undocumented behavior of a
Microsoft function called by an undocumented base library function,
which still seems highly fishy.  On posix systems, canonicalizePath
calles realpath, which isn't very well documented, but at least seems
to be designed to do what we want (and apparently even works, on
Dmitry's system).  There's no documentation that I can find indicating
what realpath does when given a path describing a nonexistent file or
directory, but we could always hope that it does what we want.

There are also issues such as the fact that canonicalizePath
introduces a maximum filepath limitation that isn't present in the
Windows API.  The POSIX function realpath has an inherent maximum path
length in the API, which is inherent in the POSIX API.  Of course, it
may be that many of the ghc functions involving file paths have a
PATH_MAX size limit, in which case this may be a moot point, I don't
know.

David


More information about the darcs-users mailing list