Closed Bug 259321 Opened 20 years ago Closed 19 years ago

Cannot erase existing mail folders which have names in Khmer

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: javier, Assigned: mscott)

References

Details

(Keywords: intl)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 Build Identifier: Thunderbird 0.7.3 Sometimes, empty mail folders which have names in Khmer (Unicode range 1780 - 17FF) cannot be erased. The deletion process does not succeed and there does not seem to be possible to erase the folders. Reproducible: Sometimes Steps to Reproduce: 1.Enable Khmer in the computer (fonts, keyboard, latest version of usp10.dll 2. Create a mail folder that has a name in Khmer. Assure that it has no mail. 3. Attempt to delete de folder Actual Results: Sometimes the mail folder is deleted, sometimes not. Expected Results: Should be deleted always. This might relate to bug 259317 (mail folders with Khmer names sometimes cannot be created, the are wrongly considered to exist already).
Blocks: 259227
Keywords: intl
I experienced same problem for Japanese folder name which is newly created by Mozilla 1.8a4 Release build(and latest nightly) and Thunderbird 0.8 Release build on Win-2K,NTFS drive. Test Scenario is as follows : (Case-1) No illegal file name character byte (1-1) Create a folder named "TEST-1" (1-2) Create a folder with a Japanese character(0x82A0 in Shift_JIS, first HIRAGANA character, pronounced "er") Next 3 files were created under TEST-1.sbd directry. bd0bf789 bd0bf789.msf <0x82A0> (1-3) Delete this folder Next 4 files were created under Trash.sbd directry. bd0bf789 bd0bf789.msf <0x82A0> <0x82A0>.msf <= Newly Created (1-4) Check TEST-1.sbd Next 1 file still remained in TEST-1.sbd directry <0x82A0> (Case-2) Illegal file name character at second byte (2-1) Create a folder named "TEST-2" (2-2) Create a folder with a Japanese character(0x835C in Shift_JIS, 15-th KATAKANA character, pronounced "so") Next 2 files were created under TEST-2.sbd directry. bd0bf789 bd0bf789.msf (2-3) Delete this folder Next 2 files were created under Trash.sbd directry. bd0bf789 bd0bf789.msf (2-4) Check TEST-2.sbd No file was found (Case-2) is a normal result when a illegal file name character(0x5C,\) at second byte of double byte character. (See Bug 117385) When no illegal file character byte is contained in Shift_JIS code of Japanese character, former Mozilla created file set of <0x82A0> and <0x82A0>.msf for Japanese folder name. However, current Mozilla created "hexa-string" and "hexa-string".msf files although no illegal character is included. Please note that currently used my Japanese name folders are set of JAPANESE-chars file and JAPANESE-chars.msf file, and are accessed with no error. Status of (1-2) causes duplicate folders named <0x82A0> after restart ; - a set of bd0bf789 and bd0bf789.msf (Japanese folder name is saved in .msf) - a set of <0x82A0> and <0x82A0>.msf(recreated on restart) Status of (1-4) causes "already exists" on re-define. Status of (1-2),(1-3) and (1-4) sometimes causes delete failure. I belive this is blocker of Thunderbird 1.0. Javier SOLA, is your case same as mine? If same, what is your exact Thunderbird version? I tested above on Thunderbird 0.7.3 release build, but problem did exist.
Correction (Sorry for spam) : (Invalid) > I tested above on Thunderbird 0.7.3 release build, but problem did exist. (Valid) > I tested above on Thunderbird 0.7.3 release build, but problem did NOT exist.
Problem did not exist on Mozilla Suite 1.8.a3 Release build. (Build ID of Win-32 ZIP build = 2004-08-17-07) So this problem was produced after 2004/8/17. Following is Bonsai's report for changes since 2004/08/17 00:00:00 to now on mozilla/ mailnews/ local/ src/ nsLocalMailFolder.cpp 2004-09-15 16:04 bienvenu%nventure.com 1.477 10/1 fix downloading partial pop3 messages for offline when they've been filtered into other folders, sr=mscott 259649 2004-08-30 09:57 bienvenu%nventure.com 1.476 8/0 fix 257104, empty local trash doesn't set counts to zero, sr=mscott 2004-08-23 10:55 bienvenu%nventure.com 1.475 1/1 fix 256332 compact breaks rss folders, also fix runtime warnings in account manager sr=mscott 2004-08-18 16:46 timeless%mozdev.org 1.474 1/1 Bug 41929 - movemail. fixing build bustage 2004-08-18 16:11 neil%parkwaycc.co.uk 1.473 34/53 Bug 41929 Allow multiple accounts with the same server and username if they have different port numbers p=kteuscher@myrealbox.com r=bienvenu sr=me 2004-08-18 14:54 scott%scott-macgregor.org 1.472 4/2 Bug #219586-->Eudora, Outlook mailboxes with "/" in name fail to import. Unable to create local folders with forward slashes in the name on Windows. sr=bienvenu Scott, regression by patch for Bug 219586?
Main cause of problems was existence of <0x82A0> file(file name of Japanese character) at step (1-2) of (Case-1) in my Comment #1. Manual deletion of <0x82A0> file just after folder creation resolved all following problems(duped folders after restart/undeletable folder/redefinition failure). This result indicates that set of bd0bf789/bd0bf789.msf itself is valid folder file set. (Japanese folder name is saved in .msf. Same as illegal file name character case), Main fault is creation of <0x82A0> file in addition to bd0bf789/bd0bf789.msf file set. "Treating all Japanese characters as illegal file name character" itself works very well, because "placing Japanese folder name in .msf" mechanism works completely. I guess this "Treating all Japanese characters as illegal file name character" is a result of Scot's patch for Bug 219586. Scot, is it right? However, this "Treating all Japanese characters as illegal file name character" is very incovinient for all Japanese people. It is too difficult to know "Japanese mail folder name" from hexa-string mail folder files. This causes severe difficulty in manual recovery of mail folder files.
Correction of file names of (Case-2) in my Comment #1 (Sorry again for spam). (Invalid) bd0bf789 bd0bf789.msf (Valid) 3db4214a 3db4214a.msf
I've found a easy workaround - "Do not use non-ASCI" on folder creation. (1) Create folder with non-ASCII characters only. (2) Rename the folder to name with non-ASCII.
I've opened Bug 264071, since my problem is Mozilla problem. Javier SOLA, see Bug 264071 if your problem is on Thunderbird builds after 0.7.3 release build.
Correction of workaround(Sorry for spam). (1) Create folder with ASCII characters only. (2) Rename the folder to name with non-ASCII. (Invalid) > (1) Create folder with *non-*ASCII characters only. > (2) Rename the folder to name with non-ASCII.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.