[Webkit-unassigned] [Bug 81270] FileApi does not handle files with NFD encoded umlaut in file name

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=81270





--- Comment #18 from Eric U. <ericu at chromium.org>  2012-03-21 10:08:18 PST ---
(In reply to comment #16)
> This sounds more like a Linux file system issue than anything else. Are all Linux file systems like this, or just some of them? This can be seen as a configuration issue - users that want Unicode in file names to work should use a Unicode aware file system.

It's more a system issue than a filesystem issue, I believe, and yes, all Linux filesystems are like this.  It's not a configuration option--ext[23], reiser, etc. just don't store or deal with encoding information, and you set environment variables to tell your tools what to expect.  The kernel just treats strings as bytes, with the exceptions that a NUL is a terminator and a slash is a directory separator.  Beyond that, it knows nothing.

The Linux ntfs drivers probably deal with unicode interpretation, but those aren't common as main Linux filesystems.  http://hektor.umcs.lublin.pl/~mikosmul/computing/articles/linux-unicode.html suggests that mounting FAT drives [including USB] with the right options might help, but I've not seen that proven.  Still, if that fixed USB, and the download manager fixed downloaded paths, we'd have solved the known sources.  Doesn't seem a robust solution, though, since there might be other sources.

> > The user could also just plug in a USB drive with denormalized paths on it
> 
> Is this a practical scenario? How would they get non-NFC paths on the USB drive?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.