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

Jason Dagit dagit at codersbase.com
Fri Sep 26 15:10:54 UTC 2008


On Fri, Sep 26, 2008 at 7:11 AM, David Roundy <droundy at darcs.net> wrote:

> 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.


Are you rejecting the whole bundle due to the last patch?  I'm asking, would
you accept the rest if the last patch was rewritten to not use
System.Directory.canonicalizePath?

Docs Analysis
---------------------------

For anyone reading along at home, the Windows specific part of
canonicalizePath calls this function:
http://msdn.microsoft.com/en-us/library/aa364963(VS.85).aspx



>
> 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.


For realpath I found this:
http://www.manpagez.com/man/3/realpath/
http://manpages.ubuntu.com/manpages/hardy/man3/realpath.html

The ubuntu man page has error codes that make it very much seem that the
file name must exist.  On Debian Lenny I installed the package 'realpath'
which is a command line wrapper around realpath(3) and I see this:
$ realpath /tmp
/tmp

$ realpath /foo
/foo: No such file or directory

So it seems that realpath(3) may very well require the path to be real :(

For GetFullPathName (called on windows) there is this:
*"GetFullPathName* does not convert the specified file name, *lpFileName*.
If the specified file name exists, you can use
*GetLongPathName*<http://msdn.microsoft.com/en-us/library/aa364980%28VS.85%29.aspx>or
*GetShortPathName*<http://msdn.microsoft.com/en-us/library/aa364989%28VS.85%29.aspx>to
convert to long or short path names, respectively.

So, I think the windows version at least can be called when the file name
does not exist.

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.


A possibly different max path will be imposed on windows.  It seems that
maximum is based on which version of windows you're running and if you
provide the unicode prefix "//?/".

--------------------------

Now that we've analyzed the documentation.  Just wondering, why do we
canonicalize non-existent paths?  Is this for handling removes?


This thread should probably be summarized and sent to the maintainer of
canonicalizePath as it seems like documentation updates are in order.

Thanks,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20080926/eebc07c4/attachment-0001.htm 


More information about the darcs-users mailing list