I haven't picked all the way through this yet, but quick observations are:ġ) if it's a virtual folder, it just calls nsMsgDBFolder::Rename() and leaves it at that.Ģ) the pluggable message store isn't used.ģ) it calls both nsImapMailFolder::RenameClient() and nsImapMailFolder::RenameLocal(). Later on, they'll be a nsImapIncomingServer::OnlineFolderRename() coming in, where the local imap folder renaming is handled. NsImapMailFolder::Rename() just tells the server to rename the folder.
msf file (actually, I'm not sure this should be done by the msgStore)ģ) checks up on any filters which might be referencing the folderĤ) calls RenameSubFolders() which recursively creates new child folders, checking for filter usage as it goes.ĥ) detaches the old folder from the parent (and calls progagateDelete() on it) and adds the new one.Ħ) tells the nsIMsgFolderNotificationService that the folder has been renamed. NsMsgLocalMailFolder::Rename() performs these steps:ġ) calls nsIMsgPluggableStore::RenameFolder() to rename the raw filesystem artifacts: Here are my notes - mostly a braindump for my own reference: Issue, but I think you can fix and close this bug quite easily by fixing issue 1. If not, then the case-independence of the renamingĬheck is not a problem, and only problem 1. If so, then the rename check should be case-dependent, and The other issue is, should it be permissable to have two folders whose namesĭiffer only by case. That name already exists" alert is thrown.įixing this would fix the problem described in comment 3, without having toĢ. Would not cause a problem since it doesn't change the state of the folders inĪny way. Just click on "rename folder", and then hit ENTER. Note that this bug is independent of case, as can be seen when you try toĮxecute a rename that doesn't change anything, neither the name nor the case. Duplicate checking should be against all foldersĮxcept the one being renamed, since the name of the folder being renamed willĭisappear in the process of renaming anyhow. When renaming folders, the new name should not be duplicate-checked against Folks, I think there are two separate but similar bugs here:ġ.
0 kommentar(er)
