On Oct 4, 2011, at 11:56 AM, Erich Hoover wrote: > On Tue, Oct 4, 2011 at 11:36 AM, Charles Davis <cda...@mymail.mines.edu> > wrote: >> On Oct 4, 2011, at 9:32 AM, Erich Hoover wrote: >>> This patch implements GetVolumePathName by using the full folder >>> path and working backward until stat() returns a different device. >> Surely there's a better way. Can't you do a statfs(2)/statvfs(2) (for >> example) to find out the FS root? (I know that works on the BSDs and Mac OS, >> because their statfs/statvfs structures all have a field for >> that--f_mntonname.) Then you can map that path back to a Wine path, and >> return that. Of course, that won't work for fake drives (see below). > > I doubt it, the function needs to return the mount point along the > given path (see MSDN). In the case of cross-device symbolic links > your suggestion will not return the current path. Ah, you're right. MSDN says that GetVolumePathName() returns the volume containing the target of the symlink... unless of course, the path is a remote one. (Same for mounted volumes.) But that isn't a common case, nor is it one that Wine even supports yet :). > >> At the very least, you should be caching this information, like I did when I >> added case-insensitive lookup support to Wine (see commit >> 4e44e153c5c78339f17baeabe22f2015cfc8737c). Because you call stat(2) on every >> single directory in a pathname (especially in the common case of the file >> being on the root device), calculating this from scratch is extremely >> expensive. > > I'm not sure this function is used enough to justify caching the > results, as this is the first time I've noticed the FIXME on the > console. If someone thinks that is the case then I can always make > that a "part 2" patch. OK. > >> And what about drive C? On Wine, that's not a device at all. It's a folder >> usually somewhere on the root device. In general, I don't see anything in >> your patch that accounts for fake drives like C:--the common case, I might >> add! > > If you pass it just the path to "C:\" then it will spit back "C:\", > since it only encounters the one filesystem. If you pass something > like "C:\windows\system32\" then it will spit back "C:\" unless the > "windows" or "system32" folders are symbolic links to a folder on > another drive. Ah, I read your patch wrong. Never mind.
Chip
