Closed Bug 273753 Opened 20 years ago Closed 20 years ago

Folders who names begin with a . as first character disappear with all their contents!

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 229522

People

(Reporter: feedback, Assigned: mscott)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Thunderbird version 1.0 (20041206)

Renaming folders, or having migrated from Outlook with folders that have a .
character as first character, see folders disappear completely when Thunderbird
is restarted!

Reproducible: Always
Steps to Reproduce:
1. Rename a folder with . as first character
2.
3.

Actual Results:  
close and reopen thunderbird and the folder and its messages have disappeared.

Expected Results:  
Re-opened with all folders displayed as they were.

I wonder there are other characters that do this but can't find any immediately..
Hello guys,

I could reproduce the same behavior on my Windows 2003 Server. After spending
some time with LXR and my debug build, I found the source code explaining the
behavior. 

In /mailnews/local/src/nsLocalMailFolder.cpp,

192 static PRBool
193 nsShouldIgnoreFile(nsString& name)
194 {
195   PRUnichar firstChar=name.CharAt(0);
196   if (firstChar == '.' || firstChar == '#' || name.CharAt(name.Length() - 1)
== '~')
197     return PR_TRUE;
...

237 nsresult
238 nsMsgLocalMailFolder::CreateSubFolders(nsFileSpec &path)
239 {
...
251 
252     // here we should handle the case where the current file is a .sbd
directory w/o
253     // a matching folder file, or a directory w/o the name .sbd
254     if (nsShouldIgnoreFile(currentFolderNameStr))
255       continue;
...

It seems that mozilla mail ignores files starts with '.' or '#'. However, the
case of '#' is handled correctly by using hash string as filename. The
NS_MsgHashIfNecessary() function is responsible for that. 

763 nsresult
764 nsMsgLocalMailFolder::CreateSubfolder(const PRUnichar *folderName,
nsIMsgWindow *msgWindow )
765 {
...
777   //Now we have a valid directory or we have returned.
778   //Make sure the new folder name is valid
779   nsAutoString safeFolderName(folderName);
780   NS_MsgHashIfNecessary(safeFolderName);
...

In /mailnews/base/util/nsMsgUtils.cpp,

265 nsresult NS_MsgHashIfNecessary(nsCAutoString &name)
266 {
267   NS_NAMED_LITERAL_CSTRING (illegalChars, 
268                             FILE_PATH_SEPARATOR FILE_ILLEGAL_CHARACTERS
ILLEGAL_FOLDER_CHARS);
269   nsCAutoString str(name);
270 
271   // Given a filename, make it safe for filesystem
272   // certain filenames require hashing because they 
273   // are too long or contain illegal characters
274   PRInt32 illegalCharacterIndex = str.FindCharInSet(illegalChars);
275   char hashedname[MAX_LEN + 1];
276   if (illegalCharacterIndex == kNotFound) 
277   {
...
287   }
288   else 
289   {
290       // found illegal chars, hash the whole thing
...
299   }
...

Here, 'illegalChars' contains '#' but not '.'. In summary, mozilla mail allows
user to create folder name starts with '.' but it ignores it after that. I
wonder if there is specific reason of ignoring the files start with '.'. If
then, we need to add '.' to 'illegalChars' (probably add to ILLEGAL_FOLDER_CHARS?).

By the way, this is my second day with mozilla source code and bugzilla ;-) I
hope this information helps to confirm the bug.
added myself to CC.
I forgot to mention a workaoround of this bug. ;-) If you go to your mailbox
directory and simply change the filenames (3 files for each folder) not to start
with '.' then it will re-appear.
DUP of Bug 229522. See dependency tree for Bug 124287.
As you say, I also think considering first "." as a illegal file name
character(use hash) is easiest and effective solution.
Your proposal will be effective and work well, I belive.
Jeongkyu Kim, could you please post your pach to Bug 229522?
I'm very appriciated if you add ending "."(dot) and ending "~"(tilde) cases in
your patch for Bug 117840 and Bug 198966.
Regards.

*** This bug has been marked as a duplicate of 229522 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
WADA,
Thanks for your comment. I posted two patcheds to bug Bug 229522. 

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