To be perfectly honest, I don't care which way it is "fixed", as long as the
result still points to the right file.
And now some history: the version of File::Spec::Win32 in Perl 5.8.0 did no
".." processing in canonpath(), and that was fine. As of Perl 5.8.1, the
canonpath() started doing the broken ".." processing. So, this patch assumed
that the ".." simplification was desired, and fixed that.
Either roll back that method to the 5.8.0 version, or apply the patch. The
current behavior is the worst of the three choices, IMHO ...
TD
-----Original Message-----
From: Ken Williams
To: Michael G Schwern
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 7/6/2005 4:10 PM
Subject: Re: [perl #27052] File::Spec->canonpath("a\\..\\..\\b") returns
wrong value for Win 32
On Jul 6, 2005, at 2:50 PM, Michael G Schwern wrote:
> On Wed, Jul 06, 2005 at 02:06:19PM -0500, Ken Williams wrote:
>> On Jul 6, 2005, at 11:29 AM, Michael G Schwern via RT wrote:
>>
>>> [tomdinger - Tue Feb 24 10:15:24 2004]:
>>>> Under Windows (using File::Spec::Win32), the call
>>>> File::Spec->canonpath('a\\..\\..\\b\\c') returns the wrong value:
>>>> 'b\\c'.
>>>> It should return '..\\b\\c'.
>>>
>>> Hey Ken, want to have a look at this? There's a patch and
>>> everything!
>>
>> If Win32 is going to be handled like Unix, then it should return the
>> input verbatim (".." is not cleaned up). Is there a reason it should
>> be different on Win32?
>
> That's not the issue. b\c is right out wrong. Examine the path
> closer.
>
> a\..\..\b\c
>
> "a\.." cancels out leaving "..\b\c".
Right, I understand the bug, I'm just trying to get the right fix.
Note that I suggested that it return that particular input string
verbatim.
> PS Offhand the reason I can think for cleaning up .. on Win32 is
> because it
> tends to not have symlinks to worry about so a\..\a\ should equal a\
>
"tends not to" isn't a good enough reason in this case. If it treats
them differently, though, that might be a good enough reason.
-Ken
