If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.
If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants. AppendASCII
exists to stick new ASCII components onto existing FilePaths. This is
fine and is considered safe because ASCII is a subset of any rational
filesystem encoding.
If you've got to take an arbitrary FilePath and convert it for display
to the user, or take an arbitrary string in a known encoding and
re-encode it for the filesystem, then we don't have anything in
FilePath for this. I believe that if we do add something, it should
strictly operate only on single pathname components at a time, and not
entire pathnames. We could add it to FilePath or we could add it
somewhere else, because it is sort of distinct from what FilePath is
really supposed to be, which is just a container for ferrying around
native paths.
>> It's also a specification and implementation nightmare. Everyone has
>> a different idea of what "normalization" means. What's your idea?
>
> Yes, I know it's a nightmare all around, but I think it would be useful to
> have something that addresses this. My idea would be the same as Python's
> os.path.normpath, mainly because it's a well-tested, seasoned example with
> test cases. Windows also has a routine for this (PathCanonicalize) that
> could be used (but I know it doesn't work for UNC paths).
Why would it be useful? Do you want to compare paths for equality?
Then we should have an API that compares paths for equality. It would
have to hit the disk to do so. You might need general-purpose
canonization to implement that on some systems. Great, you need to
hit the disk to do that too. It's fine if you want these things, but
we can't put them into FilePath. It's important that FilePath remain
lightweight and not make any system calls, because system calls can
block and FilePath is just a data carrier.
os.path.normpath is known to be buggy. It might be well-tested and
seasoned, but only within the confines of its known limitations.
Watch this.
m...@anodizer bash$ ls -l a/b/../c
-rw-r--r-- 1 mark staff 0 May 13 15:47 a/b/../c
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.normpath('a/b/../c')
'a/c'
>>> ^D
m...@anodizer bash$ ls -l a/c
ls: a/c: No such file or directory
> Probably the same as os.path.normcase in Python. I want this stuff so that
> I can make sure that I can at least semi-reliably compare/manipulate
> FilePaths to do things like absolute->relative path conversion, or store
> FilePaths in a set or map and be sure I don't have multiple entries pointing
> to the same file. Without these kinds of operations, doing these things is
> pretty much impossible.
I don't think os.path.normcase does what you're asking for either.
m...@anodizer bash$ ls -lid /System/Library
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /System/Library
m...@anodizer bash$ ls -lid /system/LIBRARY
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /system/LIBRARY
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.platform
'darwin'
>>> import os.path
>>> os.path.normcase('/System/Library')
'/System/Library'
>>> os.path.normcase('/system/LIBRARY')
'/system/LIBRARY'
>>> ^D
Even os.path.realpath returns the same results.
Again, it sounds like what you really want is a pathname comparator
that hits the disk. You really can't do this stuff correctly on most
systems without talking to the filesystem. You can't even do
general-purpose canonization without talking to the filesystem.
Let me make clear: I'm not trying to shoot down the idea of needing to
be able to compare paths or even necessarily canonize them. I'm
arguing primarily against doing it in FilePath, but I'm also also
trying to illustrate that doing proper comparisons and canonization is
harder than it seems, that even "seasoned and well-tested" APIs are
limited in ways that developers don't necessarily expect, and that the
semantics and expectations need to be well-defined.
Mark
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
