On Wed, May 13, 2009 at 7:24 PM, Brett Wilson <[email protected]> wrote:
> You can't actually canonicalize a filename on Windows, so I think it's > dangerous to write a component that claims to do it. You can do it under controlled conditions, and especially if the file exists on the disk already and is accessible. For instance, if you don't try to handle (non-deterministic) 8.3 names of files that don't exist yet/anymore and NTFS mount points, I think you can fairly safely apply the "regular" rules to canonicalize paths (and even if you applied the rules to those, most of the time they would still work). I would make sure that the class only claims to canonicalize paths that it really knows it can do, of course. Look, I know there are tough problems here, but why not TRY to solve them as well as possible. FilePath is fine for simple manipulations, and is a good, lightweight container if you're not planning on doing anything complex with the file names. If you actually need to do more interesting things with them, like display the names, convert to relative paths, compare them for equality or pass them off to a third party in a particular encoding, it's not sufficient. I could write a half-assed implementation that kinda works if you don't throw anything wonky at it. I've got that now. I want something more bulletproof. It can't be perfect because file paths are non-deterministic on all three systems in not so obvious ways, but why should everyone who needs more than FilePath have to climb that learning curve? And we can only give out information that is as good as we get from the OS -- if the OS isn't able to present a filesystem that makes sense, we can only provide the best gibberish we can get our hands on. -Greg. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
