Thunderbird:Pluggable Store Migration: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
 
Line 1: Line 1:
Migration is conceptually fairly easy. We iterate over the folders in the source store, create the folder in the target store, and then stream each message in the source folder to target folder. In order to avoid file collisions, especially for file based stores like berkeley mailbox and maildir, we'll need to write to a different directory and then either point the account at the new directory, or delete the original folders from the directory. But we also have to worry about other files stored in the profile directory (msgFilterRules.dat, popstate.dat, feeds.rdf, hostinfo.dat and the like). Either we hardcode the knowledge of those files, or we clone the whole directory, delete the folders from the clone, and then stream the folders into the clone, and then change the server to point at the new clone directory. Or temporarily point the server at the clone directory, delete the folders from the original, and stream from the clone to the original, and then point the server back at the original directory. I want to be very cautious about deleting the original store, since for the pop3 case, that's the user's mail. But we have to give the user some way of deleting the original store. And I want to make unwinding from errors in the migration easier. That all points to a strategy of leaving the original server directory alone, and writing into a new directory, and then switching the server directory at the very end.
Migration is conceptually fairly easy. We iterate over the folders in the source store, create the folder in the target store, and then stream each message in the source folder to target folder. In order to avoid file collisions, especially for file based stores like berkeley mailbox and maildir, we'll need to write to a different directory and then either point the account at the new directory, or delete the original folders from the directory. But we also have to worry about other files stored in the profile directory (msgFilterRules.dat, popstate.dat, feeds.rdf, hostinfo.dat and the like). Either we hardcode the knowledge of those files, or we clone the whole directory, delete the folders from the clone, and then stream the folders into the clone, and then change the server to point at the new clone directory. Or temporarily point the server at the clone directory, delete the folders from the original, and stream from the clone to the original, and then point the server back at the original directory. I want to be very cautious about deleting the original store, since for the pop3 case, that's the user's mail. But we have to give the user some way of deleting the original store. And I want to make unwinding from errors in the migration easier. That all points to a strategy of leaving the original server directory alone, and writing into a new directory, and then switching the server directory at the very end. But some users are very particular about their server directory, so changing it is potentially rude. We could stream to a new temp dir, rename the old dir, rename the new temp dir to the original dir name, and then delete the renamed old dir.
 
What if the store being migrated is a cloud store? In that case, the special files like popstate.dat are probably the only ones we care about copying.


I think we need to create a temporary dest server object and set its directory to the target directory, set the pluggable store for the temp dest server to be the new store type, and then create a root folder for that server. That root folder will be used as the root for all the folders we create after that. We'll need to remove the temp server when we're done.  
I think we need to create a temporary dest server object and set its directory to the target directory, set the pluggable store for the temp dest server to be the new store type, and then create a root folder for that server. That root folder will be used as the root for all the folders we create after that. We'll need to remove the temp server when we're done.  
589

edits

Navigation menu