262922 - nsLocalFileWin's DirectoryEnumerator needs to use UTF16 functions if available

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

nsLocalFileWin's DirectoryEnumerator implementation is using PR_OpenDir and
PR_ReadDir, which makes any non-ASCII characters in filenames be returned as '?'
as it's calling FindFirstFile/FindNextFile internally.  It needs to use
PR_OpenDirUTF16/PR_ReadDirUTF16 if they don't return not implemented.

This is causing import of IE bookmarks with non-ASCII characters in them to
fail, e.g. bug 235495.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: 262922-localfilewin-utf16-0.patch

Here's a first cut at a patch... of course, the problem is that we don't seem
to build firefox with MOZ_UNICODE, so I'm kinda stuck here for fixing the
depending bug...

Comment 2

[Darin Fisher]

vlad: yeah, there's a reason why MOZ_UNICODE is not defined.  those APIs are
experimental.  see bug 239279 for all the gory details, and the solution that
has been proposed.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ugh.  Any ideas for possible solutions to bug 235495 then?  We're getting bogus
data out of nspr right now.. I guess as a 1.0 bandaid, I can maybe do the
function lookup for the unicode functions myself in nsIEProfileMigrator and use
them directly instead of the enumerator, but that's getting rather gross.  Not
sure what else to do, though.

(Also: attached patch has a bug; the Init method needs to use the right string,
either GetPath or GetNativePath, instead of always using the Native method to
get a CString.)

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Was this fixed by bug 162361?

Comment 5

[Jungshik Shin]

yes, it must have been.