Bugzilla

Copy to my ISP server from comfine server worked with no errors. 

Another interesting factoid: My ISP's server seems unable to fetch the requested header items and returns empty. However, all message are present and completely accessible when opened, just subject, correspondent etc are blank on the message list. I think this is because the headers from jdien07's mailing list are too complex or maybe too long for my ISP's server (Openwave) to parse.

Now copying back  the 17k messages to comfine server from ISP's Openwave is in progress...

Well, didn't go so well:
0. 3260 messages copied OK. Message ID 3261 fetched from Openwave OK.
1. Tb appended message ID 3261 at destination comfine server. Good.
2. Tb fetched next message ID 3262 from openwave, got only part of 226550 bytes message and
3. Openwave issued a tcp FIN causing a disconnect. Don't know why.
4. Tb immediately opened a new connection and fetches flags as expected.
5. Tb then fully fetched message 3262, all 226550 bytes using the new connection.
6. No append to comfine occurs as it should, so **copy stops**.
7. Last progress logged "CopyNextStreamMessage: Copying 3261 of 17257
8. Connection to comfine times out after a while due to inactivity as expected.

So this is an example of how a copy starts, runs for a while and then just stops. No errors are logged or notified to the user. 

However, I'm not sure this is what the typical commenter to this bug is doing. For one thing, I am running the openwave and comfine accounts *without* offline store. So copy between them has to fetch the messages from the source server before appending to the destination server. When the bulk copy is from Local Folder or from an imap folder **with offline store**, the message to be appended is obtained directly from file and no fetch on the network of the message typically occurs. So having offline store should eliminate the error seen above, and I've not seen this when the source folder is in Local Folders.

However, the copy process should be able to fully recover from the above problem. It currently partially recovers by re-fetching the incomplete (due to openwave disconnect) message; but does not continue on and append the correctly fetched message to the destination server. The question is why not?

Copy to my ISP server from comfine server worked with no errors. 

Another interesting factoid: My ISP's server seems unable to fetch the requested header items and returns empty. However, all message are present and completely accessible when opened, just subject, correspondent etc are blank on the message list. I think this is because the headers from jdien07's mailing list are too complex or maybe too long for my ISP's server (Openwave) to parse.

Now copying back  the 17k messages to comfine server from ISP's Openwave is in progress...

Well, didn't go so well:
1. 3260 messages copied OK. Message ID 3261 fetched from Openwave OK.
1. Tb appended message ID 3261 at destination comfine server. Good.
2. Tb fetched next message ID 3262 from openwave, got only part of 226550 bytes message and
3. Openwave issued a tcp FIN causing a disconnect. Don't know why.
4. Tb immediately opened a new connection and fetches flags as expected.
5. Tb then fully fetched message 3262, all 226550 bytes using the new connection.
6. No append to comfine occurs as it should, so **copy stops**.
7. Last progress logged "CopyNextStreamMessage: Copying 3261 of 17257
8. Connection to comfine times out after a while due to inactivity as expected.

So this is an example of how a copy starts, runs for a while and then just stops. No errors are logged or notified to the user. 

However, I'm not sure this is what the typical commenter to this bug is doing. For one thing, I am running the openwave and comfine accounts *without* offline store. So copy between them has to fetch the messages from the source server before appending to the destination server. When the bulk copy is from Local Folder or from an imap folder **with offline store**, the message to be appended is obtained directly from file and no fetch on the network of the message typically occurs. So having offline store should eliminate the error seen above, and I've not seen this when the source folder is in Local Folders.

However, the copy process should be able to fully recover from the above problem. It currently partially recovers by re-fetching the incomplete (due to openwave disconnect) message; but does not continue on and append the correctly fetched message to the destination server. The question is why not?

Copy to my ISP server from comfine server worked with no errors. 

Another interesting factoid: My ISP's server seems unable to fetch the requested header items and returns empty. However, all message are present and completely accessible when opened, just subject, correspondent etc are blank on the message list. I think this is because the headers from jdien07's mailing list are too complex or maybe too long for my ISP's server (Openwave) to parse.

Now copying back  the 17k messages to comfine server from ISP's Openwave is in progress...

Well, didn't go so well:
1. 3260 messages copied OK. Message ID 3261 fetched from Openwave OK.
1. Tb appended message ID 3261 at destination comfine server. Good.
2. Tb fetched next message ID 3262 from openwave, got only part of 226550 bytes message and
3. Openwave issued a tcp FIN causing a disconnect. Don't know why.
4. Tb immediately opened a new connection and fetches flags as expected.
5. Tb then fully fetched message 3262, all 226550 bytes using the new connection.
6. No append to comfine occurs as it should, so **copy stops**.
7. Last progress logged "CopyNextStreamMessage: Copying 3261 of 17257
8. Connection to comfine times out after a while due to inactivity as expected.

So this is an example of how a copy starts, runs for a while and then just stops. No errors are logged or notified to the user. 

However, I'm not sure this is what the typical commenter to this bug is doing. For one thing, I am running the openwave and comfine accounts *without* offline store. So copy between them has to fetch the messages from the source server before appending to the destination server. When the bulk copy is from Local Folder or from an imap folder **with offline store**, the message to be appended is obtained directly from file and no fetch on the network of the message typically occurs. So having offline store should eliminate the error seen above, and I've not seen this when the source folder is in Local Folders.

However, the copy process should be able to fully recover from the above problem. It currently partially recovers by re-fetching the incomplete (due to openwave disconnect) message; but does not continue on and append the correctly fetched message to the destination server. The question is why not?

Edit: Tried to resume the copy by selecting message 3261 to the end on openwave (source) server and copy to comfile (destination). Copy would not start and nothing logged. Tried twice. Had to restart tb to resume the copy. I think this was mention by others above. Apparently a variable is set and locking out further bulk copies. More to look for...