On Tue, Oct 4, 2011 at 11:36 AM, Charles Davis <[email protected]> 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. > 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. > 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. Erich Hoover [email protected]
