As it says.
Created attachment 115686 [details] Patch v1 Patch!
This method is used to manipulate a path, and it seems very fragile to expect that display name matches path component. If nothing else, path components use different Unicode normalization than regular strings in OS X.
Comment on attachment 115686 [details] Patch v1 View in context: https://bugs.webkit.org/attachment.cgi?id=115686&action=review > Source/WebKit/mac/Misc/WebNSFileManagerExtras.mm:95 > - (NSString *)_webkit_startupVolumeName > { > - NSString *path = [self _webkit_carbonPathForPath:@"/"]; > - return [path substringToIndex:[path length]-1]; > + return [[[NSFileManager defaultManager] componentsToDisplayForPath:@"/"] objectAtIndex:0]; > } While it may work OK, this doesn’t seem quite right. This method is not used to display the volume name. It’s used to compare the name with the first component in a string extracted using -[NSString pathComponents], which I do not believe does any “display” processing. So if “components to display” has any meaning other than “components” for volumes then the code will not work well.
(In reply to comment #2) > This method is used to manipulate a path, and it seems very fragile to expect that display name matches path component. If nothing else, path components use different Unicode normalization than regular strings in OS X. Ah, it seems that Alexey and I are saying the same thing.
Created attachment 116006 [details] Patch v2 This patch uses DiskArbitration to find the volume name of the startup volume.
This is the same way of retrieving the name that DiskArbitration uses internally when setting up the /Volumes/Blargh mount point directories and symlinks.
Comment on attachment 116006 [details] Patch v2 Attachment 116006 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10533091 New failing tests: platform/chromium-linux/fast/text/international/complex-joining-using-gpos.html
Landed in r100954.