Last Comment Bug 5887 - File System in Sidebar does not display upper ascii directory names
: File System in Sidebar does not display upper ascii directory names
Product: Core
Classification: Components
Component: RDF (show other bugs)
: Trunk
: x86 Windows 95
P3 critical (vote)
: ---
Assigned To: Chris Waterson
: shrirang khanzode
: Axel Hecht [:Pike]
Depends on:
Blocks: 7228
  Show dependency treegraph
Reported: 1999-05-03 17:07 PDT by msanz
Modified: 2000-12-15 18:37 PST (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image msanz 1999-05-03 17:07:34 PDT
File system in Sidebar does not display directory names that are upper ascii
(nor double-byte).
Create a directory named "téstíñg"
Click on File System on Sidebar and choose the drive where the directory is.
Note that the directory name is now "testing"
Comment 1 User image Chris Waterson 1999-05-17 22:28:59 PDT
I am using nsFileSpec, which only has a single-byte interface to get the file
names. Reassigning to John: if you make this double-byte, then I can display
int'l chars.

FWIW, I believe that the file system data source is "out", so I'm going to
change the target milestone on this to something WAY in the future.
Comment 2 User image mcmullen 1999-05-18 11:43:59 PDT
OK, so it's academic. But I'd like some pointers on exactly what's required. Is
calling nsString::GetUnicodeString() (or whatever it's called) enough? If so, you
can do it outside of nsFileSpec. I note that all the viewer clients of nsFileSpec
do this extra step themselves (see, for example, nsBrowserWindow.cpp).
Comment 3 User image bobj 1999-05-24 03:02:59 PDT
Filenames used by the OS' filesystem are encoded in charset encodings specific
to each localized OS.  On Mac: most European filenames are in MacRoman,
Japanese filenames in Shift-JIS.  On Win9x: Euro filename are in MS-Latin1,
Japanese filenames are in Shift-JIS.  On Unix: Euro filenames are in ISO-Latin1,
most Japanese filenames are in EUC-JP.  So we need to determine which encoding
is being used by the file system, so the proper to/from Unicode conversion can
be performed before reading or writing filenames.  nsString are 2-byte Unicode
(w/a special case to allow 1-byte (7-bit) ASCII).   So if nsFileSpec returns
nsString, then it will need to do the proper conversion and not the caller of
nsFileSpec.  This will also hide the platform dependency of the filesystem
Comment 4 User image leger 1999-08-30 15:28:59 PDT
Adding to cc list.
Comment 5 User image Warren Harris 1999-10-26 21:47:59 PDT
Dougt should own this now.
Comment 6 User image Frank Tang 2000-02-02 21:21:08 PST
No, you need to convert char* to PRUnichar* by using Unicode Converter. Find the 
nsIPlatformCharset service and ask for the charset of the FileName selector. 
Then ask Character Converter Manager for an nsIUnicodeDecoder for it. Then you 
convert it from char* to PRUnichar*. 
Naoki have change several code in widget to make the nsIFileWidget work. You may 
look at those code to see how he do that. He convert PRUnichar* to char* by 
using nsIUnicodeEncoder, and you just need the reverse one by using 
Comment 7 User image Doug Turner (:dougt) 2000-02-03 10:28:28 PST
The side bar should be using nsIFile.  If it does, strings returned by 
GetPath() are in UTF8.
Comment 8 User image Frank Tang 2000-02-04 09:54:35 PST
Where is the code which convert the file system text into UTF8 in nsIFile ?
rjc- yesterday you said you are dealing this this bug ?
Comment 9 User image Frank Tang 2000-02-04 09:58:31 PST
Why the method GetPath() passing char* instead of PRUnichar* / nsString ? We 
should always passing PRUnichar* or nsString in the interface for any text which 
may contain non ASCII. The interface problem is bigger than the implementation 
problem. Once the interface is wrong, you need to spend triple time to fix the 
Comment 10 User image Robert John Churchill 2000-02-04 10:42:01 PST
ftang: No, this isn't the bug I was referring to.
Comment 11 User image Makoto Kato [:m_kato] 2000-02-20 00:41:13 PST
This bug should dup to BUG 6770.
Probely, this bug will be fixed by BUG 6770's patch.
Comment 12 User image Doug Turner (:dougt) 2000-02-21 12:13:30 PST
nsIFile return strings in utf8.  If I create a file called téstíñg, and use an 
ls tool that uses nsIFile, I the path returned is téstíñg.  

This is not a nsIFile bug.

I am reassiging to waterson.  Need to use nsIFile.

(if I am missing something, please let me know)
Comment 13 User image Frank Tang 2000-02-29 11:53:01 PST
>nsIFile return strings in utf8.  If I create a file called téstíñg, and use 
>an ls tool that uses nsIFile, I the path returned is téstíñg.  
>This is not a nsIFile bug.
>I am reassiging to waterson.  Need to use nsIFile.
This sound exactly like a nsIfile problem....
1. the file system does not use UTF8 as encoding for the file system, so you 
should NOT return UTF8 unless you do explicit conversion between the file system 
charset and UTF-8
2. the file: url historially use file system charset (not UTF-8 again) in 
escaped form. To maintain the compatability with the old file: URL, we should 
treate the %xx escape in file: url as file system charset instead of escaped 
UTF-8. Therefore, the nsIFile better not use UTF-8 but file system charset.
Comment 14 User image Frank Tang 2000-02-29 12:44:01 PST
As waterson's said "File System in Sidebar" is OUT now. I cannot find the way to
show the file system in sidebar now.
Comment 15 User image Paul MacQuiddy 2000-04-13 00:44:04 PDT
qa contact to shrir for sidebar bugs
Comment 16 User image Chris Waterson 2000-06-09 09:22:54 PDT
there are like a million better ways to do this now.
Comment 17 User image shrirang khanzode 2000-09-06 10:59:00 PDT
marking verified.

Note You need to log in before you can comment on or make changes to this bug.