kernel32: Implement GetVolumePathName.

[Charles Davis]

On Oct 4, 2011, at 11:56 AM, Erich Hoover wrote:

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