qxe_realpath bug

There is a bug in qxe_realpath (realpath.c) that is responsible for a test failure on Cygwin. I've mostly got it analyzed, but my poor tired brain can't seem to take the last step. I'm going to record my analysis so far and go sleep for awhile. If somebody else sees the last step, feel free to take it. Otherwise, I'll take this up again when I'm feeling more rested. Scenario: there is a symbolic link to an absolute pathname. Then qxe_realpath iterates over the path components, basically copying from path to resolved_path, until it reaches the last component, which is a symbolic link. At that point readlink_and_correct_case returns a positive number (see realpath.c:298 in current CVS). Since the symbolic link is to an absolute pathname, the "then" clause of the condition on line 323 is taken. Here's where it goes wrong: it sets the new_path pointer back to the start of resolved_path (because we need to rewrite the entire path), but *adds abs_start(link_path) - 1* to skip over the absolute path at the beginning. So, for example, if a symbolic link c:\tmp\foo -> c:\blah\bar is being resolved, then resolved_path is currently "C:\tmp\foo" and link_path is "c:\blah\bar". Then new_path is set to point to the first backslash in resolved_path (we skip the "c:" at the beginning). But then the code just a few lines below that sets path (the one we are copying from) to the *very first character of link_path*. So we are skipping the absolute part in resolved_path, but not skipping it in link_path. When we loop around, we first copy the absolute part again. The result is that qxe_realpath returns c:\c:\blah\bar The part my tired brain can't figure out is if we should (1) not skip over the absolute part when setting new_path; or (2) skip over the absolute part when setting path to link_path. I *think* it is (1), because the link might point to a different drive. Will that break anything on Unix platforms? -- Jerry James http://www.ittc.ku.edu/~james/