On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai <[email protected]> wrote:
> 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. OK, I can see the allure of dealing in terms of lists of encoded strings so that you can encode them separately. For my purposes, I need to get a string encoded as UTF16 (on Windows) or UTF8 (on other platforms) that represents a filename so that I can pass it to third party APIs, so it has to include the path separators. But that can be done as a "join" operation when I get the string out. >> 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? Yes, for instance to be able to place them into a map or set and be sure I only have one entry for a particular file. And I want to be able to do absolute to relative path conversions (as far as possible, anyhow). And yes, I know that those are *really hard* to do properly, which argues even more for implementing one in a common library so that individual developers don't roll their own all the time, thinking that it is easy (and consequently producing buggy implementations). > 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. Which is why I proposed in my last message not putting them into FilePath, since I can see that it is not your intention that it support anything that hits the filesystem (and I can see why you would want that). 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. [...] Yes, I'm aware that you can create situations (especially with symbolic links) where the same path conversions will succeed or fail depending on the filesystem contents. This is why the class would have to have access to the filesystem. > 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. Yep. Totally agreed. (and normcase is probably not the behavior I'm looking for, you're right). > 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. Very well illustrated, and I assure you that I'm well aware that it's a bitch to do right. -Greg. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
