397976 - Problems with folder naming and renaming

Status: RESOLVED DUPLICATE of bug 92165

(Thunderbird :: General, defect)

Description

[S. Kerman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 1.5.0.10 (20070221)

Some characters that one might ordinarily want to enter in a folder name cause problems.  Among them are # and .  So one cannot name a folder "whatever #1" or "whatever No. 1".  IIRC at this point, the folder contents become inaccessible until the folder is renamed back to eliminate the problematic character.  

The naming function also does not properly handle changes of case.  Attempting to rename a folder from "new York" to "New York" or "new york" will result in a "folder already exists" error.  The folder must be renamed by adding or removing an arbitrary character or the character whose case is to be changed and then renamed to the desired name.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.



The naming function should either prevent insertion of characters it cannot handle or handle them properly.  Note that . and #, 2 characters that are known to cause problems cause the program to create a folder with a hex name rather than one that mimics the user's folder name even though they are allowable characters in Windows file and folder names.

Comment 1

[WADA:World Anti-bad-Duping Agency]

First, "one problem per a bug" is rule of buzilla.mozilla.org, so don't mix multiple problems is a bug.
Second, search bugzilla.mozilla.org well, please. Here is bugzilla.mozilla.org, not support forum, nor customer claim accepting center.

(1) Rename issue
    Search open bugs with "folder rename case" in bug summary. 
    You'll find Bug 92165.
(2) File name with hex string when special character in folder name.
    This is design - circumvention of internal issues in implementation
                   - workaround of inadequate design of OS.
    Bug 275770 is a request for kinder file name for human beings.
    DUP of Bug 275770?

    starting "." : This is Unix's hidden file indicator, so this kind of file
                   is not used as a file for mail folder in any OS.
    ending "." : MS Win creates file without ending dot, even though MS Win
                 returns OK for creation request of file with ending ".".
                 Please note that this is OS's bug, if normal OS,
                 from point of programing view, although "Spec" of MS Win.
    "#" : (a) Path to a mail folder is implemented URL like format internally.
              (mailbox: URL). And "/","#","?" are special character(delimiter)
              of URL. This make it difficult to use "#" in file name.
          (b) Excluding of file with "starting #" already exits, in addition to
              excluding file of "starting dot". So starting "#" is not usable
              as file name for a mail folder.
    In any case, "mail folder name" is held in ".msf" file.

Comment 2

[S. Kerman]

1) The examples I cited neither began nor ended the folder names with the problem characters I mentioned.  They are not tolerated when embedded within the folder name.
2)  I have no intention of spending any of my time searching the bug list.  I am not a volunteer on this project.  You should satisfy yourself that people are willing to take the time to report bugs at all and cull out the duplicates yourselves rather than admonishing people who have taken the time to report bugs.
3)  My point about hex file names was not a request for friendlier file names, just an observation that the characters I mentioned caused hex names to be used even though the Windows file system would tolerate these characters.  I recognize that other characters that Windows will not tolerate requires the use of some system to avoid embedding them literally in the file name.  However I can think of friendlier ways of doing it such as using 3 character hex codes in place of any intolerable character the way %20 is embedded in place of spaces in a URL.  A method like that would result in a highly readable folder name.  Not an important issue however IMO.

Comment 3

[Magnus Melin [:mkmelin]]

Please update to tb2.0, and keep it one issue per bug. The "just different case"- bug is bug 92165.

Are you using a pop or imap account? POP seems to work fine with # for me on trunk - IMAP not however, wonder if that regressed? xbug 115091. Though # in folders on imap doesn't work on 2.0 either...

We're all volunteers here, if you aren't even able to look at one bug WADA took his time to dig out for you, there is no point reporting it at all. Mind reading is kind of hard.

Comment 4

[S. Kerman]

POP.

Comment 5

[S. Kerman]

I know you're volunteers.  Presumably you have decided you have the time to commit to this.  I do not.  I don't agree that it's pointless to report obscure but 100% reproducible bugs with very good specificity even if it imposes a burden on the volunteers to perform the triage.

There's another issue to this: time efficiency.  Those of you who are volunteers are likely to already be familiar with the bug list.  Users who are not deeply involved in this task can waste an hour or more reading through the myriad other bug descriptions that come up even when well chosen keywords are entered.  I can't afford that time and don't consider it a good use of any users' time to relearn what project volunteers may well already know.

Comment 6

[Magnus Melin [:mkmelin]]

One or two bugs presented to you is hardly myriad.

Reopened bug 115091 about the IMAP case, but POP should be fine. (At least on tb2.0 ->).

Marking as dupe of the case sensitivity bug.