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.
15 years ago
No longer blocks: 235495
Assignee: file-handling → dougt
Component: File Handling → XPCOM
QA Contact: ian
Created attachment 161100 [details] [diff] [review] 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...
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.
Depends on: 239279
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.)
Assignee: dougt → nobody
QA Contact: xpcom
Was this fixed by bug 162361?
yes, it must have been.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Depends on: 162361
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.