FAQ

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?

-Ken

Search Discussions

  • Michael G Schwern at Jul 6, 2005 at 7:51 pm

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

    Or, if you don't want to clean up .. it can be a\..\..\b\c. But b\c is
    clearly wrong.

    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\


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern
    Just call me 'Moron Sugar'.
    http://www.somethingpositive.net/sp05182002.shtml
  • Ken Williams at Jul 6, 2005 at 8:10 pm

    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
  • Glenn Linderman at Jul 6, 2005 at 10:01 pm
    On approximately 7/6/2005 1:10 PM, came the following characters from
    the keyboard of Ken Williams:
    On Jul 6, 2005, at 2:50 PM, Michael G Schwern wrote:

    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.
    So how do Windows' "shortcuts" fit into this? They act a lot like
    softlinks interactively in Windows Explorer (but not, AFAICT, from the
    file system)?

    And then the newer versions of NTFS support "reparse points" and
    "junction points". How do they fit into this? I have no experience
    with these, but it sounds like they act a lot more like Unix links.

    Hence potentially making a\.. elimination problematical. Which may bea
    good reason for name canonicalization on Windows to not attempt to
    remove .. sequences... there is lots of Windows code out there that does
    do that, of course, I've written some of it myself... but as Windows
    changes, compatibility to itself is not guaranteed.

    --
    Glenn -- http://nevcal.com/
    ===========================
    Having identified a vast realm of ignorance, Wolfram is saying that much
    of this realm lies forever outside the light cone of human knowledge.
    -- Michael Swaine, Dr Dobbs Journal, Sept 2002
  • John Peacock at Jul 7, 2005 at 12:40 am

    Glenn Linderman wrote:
    So how do Windows' "shortcuts" fit into this? They act a lot like
    softlinks interactively in Windows Explorer (but not, AFAICT, from the
    file system)?
    Shortcuts are an abomination; don't try and support them (AFAIK only Explorer
    and newer versions of Office can deal with them).
    And then the newer versions of NTFS support "reparse points" and
    "junction points". How do they fit into this? I have no experience
    with these, but it sounds like they act a lot more like Unix links.
    NTFS has had hard links for files for some time, but only with a developer tool.
    Junctions are more like soft links, but only for directories (including remote
    folders on different machines). Reparse points are filesystem objects that give
    additional behaviors to files and folders (it is how they implemented junctions
    actually). None of which has any bearing on software running on top of NTFS,
    which has no reason to know that there is anything special about these files (in
    that sense they are more like hardlinks under *nix).

    /These aren't the droids we're looking for. Move along, move along!/

    John

    --
    John Peacock
    Director of Information Research and Technology
    Rowman & Littlefield Publishing Group
    4720 Boston Way
    Lanham, MD 20706
    301-459-3366 x.5010
    fax 301-429-5747
  • Nick Ing-Simmons at Jul 8, 2005 at 7:14 pm

    Ken Williams writes:
    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?
    Without (sym)links Win32 has simpler .. semantics than Unix.
    But there are still pitfalls crossing "mount" points.

    -Ken
  • Michael G Schwern via RT at Jul 12, 2005 at 9:18 pm
    Ok, enough dithering. Let's kill this bug.

    File::Spec::Win32->canonpath() currently contains code to collapse .. so
    whether or not it should continue to do so in the future is outside the
    scope of this bug. That code is also busted and is the source of this bug.

    Attached is a patch to fix this bug. It replaces the collapsing code in
    canonpath() with a more reliable method. It also moves the code into
    its own method to simplify canonpath(). _collapse() goes into
    File::Spec::Unix because it is not platform specific. Tests have been
    added for this bug in both Win32 and Unix.
  • Rafael Garcia-Suarez at Jul 19, 2005 at 8:06 am

    On 7/12/05, Michael G Schwern via RT wrote:
    Ok, enough dithering. Let's kill this bug.

    File::Spec::Win32->canonpath() currently contains code to collapse .. so
    whether or not it should continue to do so in the future is outside the
    scope of this bug. That code is also busted and is the source of this bug.

    Attached is a patch to fix this bug. It replaces the collapsing code in
    canonpath() with a more reliable method. It also moves the code into
    its own method to simplify canonpath(). _collapse() goes into
    File::Spec::Unix because it is not platform specific. Tests have been
    added for this bug in both Win32 and Unix.
    What's the status of this patch ? applied to File::Spec ? rejected ?
    updated ? (catching up over there...)
  • Ken Williams at Jul 21, 2005 at 12:50 pm

    On Jul 19, 2005, at 3:06 AM, Rafael Garcia-Suarez wrote:
    On 7/12/05, Michael G Schwern via RT wrote:
    Ok, enough dithering. Let's kill this bug.

    File::Spec::Win32->canonpath() currently contains code to collapse ..
    so
    whether or not it should continue to do so in the future is outside
    the
    scope of this bug. That code is also busted and is the source of
    this bug.

    Attached is a patch to fix this bug. It replaces the collapsing code
    in
    canonpath() with a more reliable method. It also moves the code into
    its own method to simplify canonpath(). _collapse() goes into
    File::Spec::Unix because it is not platform specific. Tests have been
    added for this bug in both Win32 and Unix.
    What's the status of this patch ? applied to File::Spec ? rejected ?
    updated ? (catching up over there...)
    Finally applied.

    -Ken

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedJul 6, '05 at 7:06p
activeJul 21, '05 at 12:50p
posts9
users7
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase