1568845 - Search folder with a '/' (slash) in the name is split to subfolders after restart

Status: NEW

(Thunderbird :: Folder and Message Lists, defect)

Description

[Honza Bambas (:mayhemer)]

TB Beta 68.0b5 (32-bit), Win.

STR:

• create a search folder with a name like 'foo/bar' and some possible (foundable) content
• it should then be a sub folder of Inbox
• restart TB

AR:

• there is a dir (common) 'foo' under Inbox now
• under 'foo' there is the search folder 'bar'
• clicking the 'bar' search folder gives a broken message pan (apparently some uncaught exception)

ER:

• apparently, the search folder is not broken by slashes.

Comment 1

[Jorg K (CEST = GMT+2)]

Is this an IMAP folder? Slashes are not allowed there, see bug 1512053.

Comment 2

[Honza Bambas (:mayhemer)]

No, forgot to mention this was a POP3 inbox.

Comment 3

[Jorg K (CEST = GMT+2)]

Hmm, on Linux? Maybe we're just handing on the slash and the directory is created under the hood. Some legacy backend issue.

Comment 4

[Ben Campbell]

Confirming this one. Occurs on Linux, with an IMAP folder.
(and to be clear, this is a search folder created via the main menu: "New..." -> "Saved Search...")

What I think is happening:
The search folder (aka virtualfolder) is created just fine.
When the user exits, nsMsgAccountManager::SaveVirtualFolders() writes out a virtualFolders.dat file.
So, after creating a search folder called foo/bar, you get this:

version=1
uri=imap://[e-mail]/INBOX/foo/bar
scope=imap://[e-mail]/INBOX
terms=AND (subject,contains,security)
searchOnline=false

When TB is run again, the nsMsgAccountManager::LoadVirtualFolders() recreates the virtual folders from the saved virtualFolders.dat.
And, of course, there's no way for it to tell that foo/bar is a folder name rather than a nested direction. Hence the screwed up UI.

In an ideal world, the folder name would be URLencoded, so virtualFolders.dat would hold:

uri=imap://[e-mail]/INBOX/foo%2Fbar

... and everything would Just Work (tm).
But this goes deep into how URIs are used/validated/sanitised (or not), and I don't think there's much consistency across the codebase.
For example, LoadVirtualFolders() won't create even create a folder for the URL-encoded version above :-(

For now I think it's probably enough to sanitise the folder name upon input (but even figuring out what characters are allowed is a little tricky!).

Anyway it's part of a bigger issue - I've stumbled into similar uncertainty elsewhere. I suspect it'd be worthwhile creating a new bug to figure out and nail down the assorted foldername naming conventions (URIs, "pretty" folder names in the UI, on the filesystem, mapping to IMAP etc etc)
Will take a look at doing this.

Comment 5

[Honza Bambas (:mayhemer)]

Note that this was reported for Windows, but seems cross-platform.

Comment 6

[Honza Bambas (:mayhemer)]

Interestingly, my workaround with using '' resulted in duplication of the folder, upon deletion of one, both disappeared.

Comment 7

[Honza Bambas (:mayhemer)]

And ':' does the same either :D

Comment 8

[Wayne Mery (:wsmwk)]

A candidate for Bug 124287 - [Meta] Problems with folders having names with illegal(or special) characters or special name ?

Comment 9

[Jorg K (CEST = GMT+2)]

Yes, Wayne, already done, see after comment #5.