OS/2, eCS & ArcaOS - Technical > Mail-News
PMMail: 2.00.xx to 3.22 migration...what to do?
ivan:
Have you tried just copying the folders over to your new install rather than running the migration tool? You might need to re-index the folders after.
I don't know if this would work but since you have a backup it shouldn't be a problem to try and if it does work you are up and running.
Dariusz Piatkowski:
ivan,
I'm afraid that is not going to work given how old my version of PMMail is. Reading through the documentation it specifically states that the Migration tool makes certain changes to the data files in order to make them usable by the new release.
I did file a request for a new ID on the bugtracker, but it's been a couple of hours now and I still have not received anything in my email. I'll give it a bit more time.
Doug Bissett:
--- Quote ---Are you suggesting that I put NEW child folders into the account specific default SENT parent folder? I thought of doing this before but I always assumed that it was a bad idea to mess with this folder. It certainly makes a lot of sense, and for starters I would be able to do a search in the SENT folders, which today causes my PMMail to simply crash.
--- End quote ---
Yes. Child folders in Sent are okay, but they should all be sent files, or you might get some strange entries in the list. That is, don't try to put both sent, and received, files in the same folder. The display is a little different.
--- Quote ---OK, so a specific issue I have is that I only have about 1.5Gig left on my application drive (also happens to be my boot drive, but that's the legacy of the original install I did). So the option I have is to move my current pmmail directory structure to a different drive, where I have a bunch of space, wipe it off of my boot drive and then do the WarpIn based install. Will the installer itself attempt to migrate the old PMMail stuff during the install, or is this a separate process one does later once the NEW PMMail install is completed?
--- End quote ---
It is really a separate process, but the migration tool is started after the WarpIn install is done, and before it terminates. In this case, I would suggest installing to the new location, and just let the tool do the copy. That is supposed to work, and it should give you the default setup, with all of your accounts, and files. Don't touch your old install, at this point. It should still work.
--- Quote ---The 2nd question is: does the migration tool/process simply need to find a disk directory structure of the old PMMail, or is it looking for some application specific install/config data?
--- End quote ---
It actually looks for the INI entry that the old PMMail puts in one of the INI files (USER.INI, I think). That should point to the old PMMail, but many users have managed to lose that entry over the years, so i would be surprised if it is there, and correct. Just point the migration tool to the old base PMMail directory, and it should do the job.
--- Quote ---Basically I am wondering if my plan to move the current install to the spare drive has a chance of working?
--- End quote ---
I think it should work, but I don't remember doing a copy to a different drive. Let's see what happens.
UHOH! something has come up. I will have to follow up later...
Dariusz Piatkowski:
Well, in the end I found out that the GROUP.DB file being 0 (zero) bytes in length is what was causing the problem. Simply including a digit (I used a 0) in the contents of the file allowed the migration tool to successfully pass that check and eventually produced a working PMMail application.
On my system attempting to do a CLI copy of that very same file produces an error, which I believe is to be expected. XCOPY on the other hand, which is also used during the migration process, does successfully copy the file over to the NEW install. At least that's what I have been able to surmize given the results I see in the filesystem folders.
OK, problem solved. I am happy to report that SMTP Authentication works well and that other than this one "gotcha" the massive amounts of my emails across three separate accounts were migrated without any other problems. This is pretty impressive given the amounts of data!
Doug Bissett:
--- Quote ---Well, in the end I found out that the GROUP.DB file being 0 (zero) bytes in length is what was causing the problem. Simply including a digit (I used a 0) in the contents of the file allowed the migration tool to successfully pass that check and eventually produced a working PMMail application.
--- End quote ---
Well, I am glad that you got it. GROUP.DB is supposed to contain the address groups. If there are no address groups, It can be zero bytes.
--- Quote ---On my system attempting to do a CLI copy of that very same file produces an error, which I believe is to be expected. XCOPY on the other hand, which is also used during the migration process, does successfully copy the file over to the NEW install. At least that's what I have been able to surmize given the results I see in the filesystem folders.
--- End quote ---
That would seem to be somewhat strange. I can copy a zero byte file, with no troubles, so there must be something wrong with that file. Possibly a bad EA, or something like that. Stranger things have happened during a migration.
--- Quote ---Given the date/time stamp of the group.db file present in the NEW directory it certianly appears that the Migration process successfully copies it over in the first place, but then fails later on as it attempts to create a backup???
--- End quote ---
The backup copy is made after the main xcopy, and before the tool modifies the file. In this case no modifications are needed, because it was empty. The copy should have worked though. The only conclusion is that the file was somehow defective. I do know, that there is a flaw in the kernel handling of defective EAs, but trying to prove that now, is probably impossible. If it is the kernel EA problem, ZIP would also crash on it, but adding the "0" seems to have fixed the problem, somehow. Now, you don't have a broken file.
--- Quote ---OK, problem solved. I am happy to report that SMTP Authentication works well and that other than this one "gotcha" the massive amounts of my emails across three separate accounts were migrated without any other problems. This is pretty impressive given the amounts of data!
--- End quote ---
Happy to hear that you got it. You probably should do a Re-Index all, in each account, before doing too much more. If GROUP.DB was not being used, it should be empty. You may want to open the file, in the editor, and remove the "0" that you put into it, otherwise, you should be good to go. Don't forget to turn off the "Leave messages on the server" flag, in each account (Receive tab), if you got that turned on. If you don't mail will pile up in the server, and that usually causes mail to be rejected.
Don't assume that everything still works exactly the same as before, but most of it will. The Help is much better, but not perfect, and the FAQ (there is a link in the PMMail Help menu) should be mostly correct.
--- Quote ---Have you tried just copying the folders over to your new install rather than running the migration tool? You might need to re-index the folders after.
--- End quote ---
That would be something to do, when nothing else will work. The problem was not in copying the folders anyway, it was in the GROUP.DB file, which is part of the address book. As I recall, the only changes are to adjust the paths to point to the new location, but there is nothing to adjust if it is empty. Copy works okay, on zero length files, so it should have worked on that one too.
--- Quote ---I'm afraid that is not going to work given how old my version of PMMail is. Reading through the documentation it specifically states that the Migration tool makes certain changes to the data files in order to make them usable by the new release.
--- End quote ---
Actually, it will work, but there may be a few things that need to be manually updated. I wrote the migration tool, and I don't remember all of the things that it does. I would need to go and read the code (it is done with DrDialog, which is REXX), and the last change was in January of 2015.
--- Quote ---I did file a request for a new ID on the bugtracker, but it's been a couple of hours now and I still have not received anything in my email. I'll give it a bit more time.
--- End quote ---
Hmmm. I am not sure who is doing that now. If it is who I think it is, it may take a day or two, but I will rattle his chain. I am not sure if it would be worth while to make a bug report, or not. I am the one who would need to look after it, and all I can do is write it off as a bad file in the original PMMail. This is definitely not the first time something like that has happened. Then again, it probably wouldn't hurt to document what happened, but I don't think there is anything to do to fix the problem, short of completely rewriting the tool, and that isn't likely to happen. It isn't perfect, but it does the job (sometimes with a few glitches).
Enjoy...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version