http://bugs.winehq.org/show_bug.cgi?id=20887
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #15 from Jörg Höhle hoehle@users.sourceforge.net 2010-07-26 11:41:13 --- Stephen's patch is incorrect.
I've written additional tests that I'll submit soon, using the =X: environment variable as suggested by AJ in http://www.winehq.org/pipermail/wine-devel/2010-July/084973.html The tests suggest the following behaviour for GetVolumeName, cf. http://www.winehq.org/pipermail/wine-devel/2010-July/084970.html 1. If path is not absolute (sadly, various definitions exist) path = merge_pathnames(path) # merge current directory of referenced drive E.g. "A:" is not absolute and merged with the per drive directory for A: (NOT to be confused with the app's unique Get/SetCurrentDirectory). 2. If path now is like A:\ then continue, otherwise return error. todo handle \?\ etc. syntax That still ignores the ERROR_DIR_NOT_ROOT case for >= w2k => more tests please (using c:\windows\ => DID_NOT_ROOT; c:\windows => INVALID_NAME)
It seems that my bug #23355 is a duplicate of this one, however comment #10 implies there's more than one issue with DA:O. My bug is about GetVolumeInformation only.
The key point is that GetVolumeInformation("A:") does not mysteriously fail. A: is merged with A:'s (per app and) per drive current directory, resulting in either a) A:\ (current directory on A is root) - ok, proceed b) A:\foo\bar\ - ERROR_INVALID_NAME || broken(ERROR_BAD_PATHNAME/*Win9x*/) The results do not seem to depend on GetDriveType (CD-ROM or HD).
I've not tested what happens on NTFS with so-called symbolic links and referencing that. I remember creating a link to the CD-ROM drive deep inside a normal directory hierarchy many years ago, and the icon of the CD appeared in the explorer...