Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, "alternative to string manipulation". FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc.
--Amanda On Wed, May 13, 2009 at 5:22 PM, Greg Spencer <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
