This post made me think that we should have infrastructure so that certain unit tests can opt to run in a restricted environment to enforce that someone doesn't come along and add filesystem-access code or other known-bad synchronous APIs.
I realize that that is probably hard, and that patches would be welcome. Just throwing it out there in hopes that someone says "Hey, I know how to do that" and someone else says "Hey, do that". -scott [It could also be a rathole that only seems like a good idea until you actually try it, like getting const-ness propagation thoroughly correct.] On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
