On Tue, Oct 4, 2011 at 11:36 AM, Charles Davis cdavis@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.
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 ehoover@mines.edu