This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: os.path.normpath over-normalizes
Type: enhancement Stage:
Components: Versions: Python 2.4
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, eljay451, georg.brandl
Priority: normal Keywords:

Created on 2008-03-14 18:43 by eljay451, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg63533 - (view) Author: John Love-Jensen (eljay451) Date: 2008-03-14 18:43
I found a bug (or at least a shortcoming) in Python's os.path.normpath routine.

It overly normalizes, at least for Unix and Unix-like systems (including Mac), and 


x = os.path.join(".", "dog", "..", "cupcake.txt")
print x
x = os.path.normpath(x)
print x

If say "dog" is a symlink (any flavor of Unix (including OS X), or Win), there is a 
difference between ./dog/../cupcake.txt and ./cupcake.txt.

In the OS, if dog is a symlink to fire/fly, the .. resolves relative to fire/fly.

It should be safe to normalize this:
././././././././cupcake.txt --> ./cupcake.txt

It should be safe to normalize this:
.////////////////cupcake.txt --> ./cupcake.txt

But this is not safe to normalize:
./x/../x/../x/../cupcake.txt --> ./cupcake.txt

For example, if the directories look like this:
./x --> over/there
./over/x --> yonder/aways
./over/yonder/x --> back/again

./cupcake.txt refers to first cupcake.
./x/../x/../x/../cupcake.txt refers to the second cupcake.

The os.path.realpath does the resolve, but sometimes the path-in-hand is for some 
arbitrary path, and not necessarily one on the local system, or if on the local 
files system may be relative based off from a different cwd.
msg63586 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-16 17:00
This is a documented feature:


Normalize a pathname. ... It should be understood that this may change 
the meaning of the path if it contains symbolic links!

See .
msg63605 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-03-16 21:53
Closing as "Won't fix".
Date User Action Args
2022-04-11 14:56:31adminsetgithub: 46542
2008-03-16 21:53:19georg.brandlsetstatus: open -> closed
resolution: wont fix
messages: + msg63605
nosy: + georg.brandl
2008-03-16 17:00:29belopolskysettype: behavior -> enhancement
messages: + msg63586
nosy: + belopolsky
2008-03-14 18:43:44eljay451create