Comment 18 for bug 85579

The patch fixes the problem described in this bug (ie, creation of local folders
with illegal chars). There are a few bugs related to local folder rename
problems (64462, 87872, etc) which will be addressed by Navin. Just want to be
clear that these problems are not caused by the patch.

The way we implement the fix is that we 'hash' the illegal folder name and use
it to create the physical files on disk. Then we store the illegal folder name
in the folder cache file so that we can carry the name from one session to
another. For example, assuming folder 'a,b' has the hashed folder name
'3d350ca7', then files 'a4eb90c2' and '3d350ca7.msf' are created on disk and the
name 'a,b' is stored in the folder cache file (panacea.dat).

One problem I found and still don't a solution to is the following scenario:

 Folder 'a,b' contains a subfolder 'a?b' and you rename 'a,b' to 'ab'.

After the rename is done you'll see that folder 'ab' now contains subfolder
'a4eb90c2' which is the hashed name for 'a?b'. The reason why this is happening
is that we remove the cache info for all the subfolder of 'a,b' when we rename
'a,b' to 'ab'. So by the time we rebuild the subfolders for 'ab' we have no idea
about the subfolders' original names and we can't hash 'a4eb90c2' back to 'a?b'.
Same problem when you lose the folder name info in the cache file (panacea.dat).

Another problem is that if you try to name 'a,b' to '3d350ca7' it'll fail
because we hash 'a,b' to '3d350ca7' and then check if file '3d350ca7' exists.
Not much we can do about this and since it's not very likely that this will
happen so we should be fine with the issue.