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.

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

No, forgot to mention this was a POP3 inbox.

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

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://testfishtimmy%40gmail.com@imap.gmail.com/INBOX/foo/bar
scope=imap://testfishtimmy%40gmail.com@imap.gmail.com/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://testfishtimmy%40gmail.com@imap.gmail.com/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.

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

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

And ':' does the same either :D

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

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