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