Mail Archives: cygwin-developers/1999/12/11/21:24:14
Applied. Thanks.
cgf
On Sat, Dec 11, 1999 at 02:49:45PM +0100, Corinna Vinschen wrote:
>Chris Faylor wrote:
>> Sorry that I didn't have time to give this my full attention earlier.
>>
>> This looks basically ok, but I think you left in a section of code that
>> shouldn't be there. It seems to run a while loop twice looking for a
>> '\\'. That can't be right. Is this just something wrong with the
>> patch?
>
>Aarg! You're right. I have checked it with an earlier snapshot and
>I was negligent when moving the patch to the latest snapshot.
>Sorry about that. It should be:
>
>==== SNIP ====
>Index: path.cc
>===================================================================
>RCS file: /src/cvsroot/winsup-991207/path.cc,v
>retrieving revision 1.1.1.1
>diff -u -p -r1.1.1.1 path.cc
>--- path.cc 1999/12/08 22:51:38 1.1.1.1
>+++ path.cc 1999/12/11 09:07:10
>@@ -221,8 +221,14 @@ path_conv::path_conv (const char *src, s
>
> /* Eat trailing slashes */
> char *tail = strchr (full_path, '\0');
>- while (tail > full_path && (*--tail == '\\'))
>- *tail = '\0';
>+ /* If path is only a drivename, Windows interprets it as
>+ the current working directory on this drive instead of
>+ the root dir which is what we want. So we need
>+ the trailing backslash in this case. */
>+ while (tail > full_path + 3 && (*--tail == '\\'))
>+ *tail = '\0';
>+ if (full_path[0] && full_path[1] == ':' && full_path[2] == '\0')
>+ strcat (full_path, "\\");
>
> if (follow_mode == SYMLINK_IGNORE)
> {
>==== SNAP ====
>
>> Also, I'm not sure what this is going to do to those mount tables which
>> have just a "c:" in them. I think they should work ok but somehow I
>> have a nagging feeling that there might be a problem there somewhere.
>
>These mount table entries of the style "c:" are the problem.
>If path_conv::get_win32() returns them, the WinAPI returns information
>for the cwd on this drive, not of the root dir.
>
>The above code only adds a trailing backslash, if the result of the
>conversion is "X:". If the result is "X:\" it leaves the backslash
>at it's position. If the result is "X:\foo\" it eats the trailing
>backslash as before.
- Raw text -