Jeff Tucker writes:
In fact, I've done just that. This machine is now running 1.6 and I've verified that UIDL returns the same UIDL as the other 1.6 clients. All three machines return the same UIDL. What do I have to do to upgrade to 2.1 and make it return the same UIDLs as the 1.6 clients? It appears to me that make install-strip, make install-configure doesn't do it as that's exactly what I did before.
A normal upgrade should do that. If this is not happening for you, there must be something else that's going on.
Make sure that you are indeed upgrading to 2.1, not 2.0. 2.0.x will not work.
OK, I'll be glad to try again. In fact, I've just downloaded the latest 20031005 snapshot and I'll try installing that. FTR, the version I'm currently running is courier-imap-1.6.0.20021025.
The original courier-imap was installed in the default /usr/lib/courier-imap location on a Linux system. I have a test account with one email in it. Checking the UIDL of that message, I see:
UIDL +OK 1 1065192807.4477000609.blade6
This matches the filename of the email file, stored on an external NFS server.
Building the new software was simple: (as jeff) ./configure make (as root) make install
In this case, I didn't run make install-configure since I had previously done that with 2.1.2. I didn't undo those changes when I went back to 1.6 as it didn't seem like extra options would hurt anything.
Now, from /usr/lib/courier-imap/libexec: ./pop3d.rc start
And now the UIDL for that same message is: 1 UID1-1065239015
Looking at the new courierpop3dsizelist file, it has two lines. This file didn't exist before, but now is:
/2 2 1065495459
1065192807.4477000609.blade6:2,S 1498 1:1065495459
So, it looks like the old UIDL was based on the filename. The new UIDL is based on this field in the courierpop3dsizelist, maybe.
Looking at the code, the important line is this:
if (msglist_a[i]->uid.n != 0)If this is true, then the UIDL is a version 1 or 2 UIDL and the pattern can't possibly match the old version 0 UIDL.
Again in the code, uid.n appears to be assigned reading out of this courierpop3dsizelist file.
I haven't studied the code in great detail, but I don't see how the system will ever end up with the filename as a modern UIDL. Sam, what am I missing? Or what were you expecting that isn't here? My old 1.6 pop3dserver.c simply prints the filename for the UIDL. What do I need to do to make 2.1.2 do the same?
Jeff
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
