This is a feature, not a bug. Or, rather, a symptom of dealing with ambiguity within differing filesystems on different versions of operating systems.

The short answer is that, without a physical file system check, you can use the no_upwards() method from File::Spec to strip your dots and double dots (or their respective equivalents on other filesystems).

The somewhat longer answer is that the OS (or filesystem implementation) is the ultimate authority on what the filesystem implementation really does. With a physical system check you can use the Cwd module and a cwd() combined with a pwd() to let the operating system figure out the correct interpretation.

The reason this is ambiguous is that soft links can span filesystems or volumes. A path involving a soft link across volumes and relative paths presents ambiguity -- if you switched volumes at some point in resolving the path, does the '..' mean backtrack to the prior volume or should it be one level up on the new volume? This is a question typically answered on the OS level.

Consider two volumes mounted thusly: 

  /mnt/disk_a
  /mnt/disk_b

[download]

and the following link/directory structure: 

  /mnt/disk_a/hubba
  /mnt/disk_a/opt -> /mnt/disk_b/opt
  /mnt/disk_b/opt
  /mnt/disk_b/hubba

[download]

Now what does /mnt/disk_a/opt/../hubba mean? It could mean either /mnt/disk_a/hubba or /mnt/disk_b/hubba depending on whether you take a tokenized or holistic approach to resolving relative directories. And to complicate matters further, soft links can also have relative paths embedded in them.

The real issue, however, is that the "proper" behavior is encoded at the filesystem implementation level. On most Unix variants, you can mount several different filesytem formats with their own interpretations of relative path resolution. But this does not prevent linking across these disparate filesystems. So though it may be more visually pleasing to eliminate those relative paths, they might be necessary to accurately resolve the behavior along OS and filesystem spec lines.

If you're relatively certain you will be operating on homogenous systems, OS as well as filesystem implementations, then by all means go for it without the physical check.

Incidentally, punting to the OS in order to let it decide what to do is the difference between cwd() and fastcwd() in the Cwd module.

Matt

Update: Also see my response below concerning the same issues regarding mount points across the network: Re^3: Absolute pathnames from relative?

In reply to Re: Absolute pathnames from relative? by mojotoad
in thread Absolute pathnames from relative? by grantm

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.