nsLocalFileWin's DirectoryEnumerator needs to use UTF16 functions if available

RESOLVED FIXED

Status

()

Core
XPCOM
RESOLVED FIXED
13 years ago
6 years ago

People

(Reporter: vlad, Assigned: vlad)

Tracking

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

13 years ago
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.
(Assignee)

Updated

13 years ago
No longer blocks: 235495

Updated

13 years ago
Assignee: file-handling → dougt
Component: File Handling → XPCOM
QA Contact: ian
(Assignee)

Comment 1

13 years ago
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...

Comment 2

13 years ago
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
(Assignee)

Comment 3

13 years ago
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.)
Blocks: 235495
Assignee: dougt → nobody
QA Contact: xpcom
Was this fixed by bug 162361?

Comment 5

11 years ago
yes, it must have been.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Depends on: 162361
Resolution: --- → FIXED

Updated

6 years ago
Assignee: nobody → vladimir
You need to log in before you can comment on or make changes to this bug.