diff --git a/mailnews/movemail/README b/mailnews/movemail/README new file mode 100644 index 000000000000..9e1d7211d92a --- /dev/null +++ b/mailnews/movemail/README @@ -0,0 +1,554 @@ +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!newsfeed.netscape.com!news.sgi.com!news.maxwell.syr.edu!hermes.visi.com!news-out.visi.com!cam-news-hub1.bbnplanet.com!news.gtei.net!newscon02!prodigy.com!darkstar.prodigy.com!davidsen +From: davidsen@tmr.com (bill davidsen) +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: 16 Jun 1999 22:06:55 GMT +Organization: TMR Associates, Schenectady NY +Lines: 32 +Message-ID: <7k975v$iao$1@newssvr03-int.news.prodigy.com> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> +NNTP-Posting-Host: darkstar.prodigy.com +X-Trace: newssvr03-int.news.prodigy.com 929570815 18776 199.4.137.118 (16 Jun 1999 22:06:55 GMT) +X-Complaints-To: abuse@prodigy.net +NNTP-Posting-Date: 16 Jun 1999 22:06:55 GMT +Originator: davidsen@darkstar.prodigy.com +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + +In article <375D61D1.B3CD128F@informatik.med.uni-giessen.de>, +Roland Mainz wrote: + +| I don't know whether this is implemented or not... +| +| Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? + +I saw this subject and thought someone was asking for the same thing I +want, a way to get the system alias file used under UNIX. All I need is +a way to disable the incorrect address "completion" feature completely, +if that's possible. + +When I send a mail about a machine problem, I want to send to admins and +get the alias which is the primary and secondary admin people for this +particular system. What I get is completion to admins@tmr.com, which is +every system administrator in the whole company. Okay, it's a small +company, but still... + +I shouldn't have to remember to type admins@localhost (generates a DNS +lookup, too) to prevent this, on a UNIX system aliases are a part of +every other mailer, and I suggest that the default should be to check +aliases before adding the domain. + +Just my pet peeve at the moment. I normally run a text only reader, +since I don't want my mail to animate, follow links, sing or install a +virus. I'm just not a trusting person, I guess. + +-- +bill davidsen CTO, TMR Associates, Inc + The Internet is not the fountain of youth, but some days it feels like +the fountain of immaturity. + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Roland Mainz +Newsgroups: netscape.public.mozilla.mail-news +Subject: Request for implementation: Support for Unix local mail +Date: Tue, 08 Jun 1999 20:32:49 +0200 +Organization: Another Netscape Collabra Server User +Lines: 23 +Message-ID: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> +NNTP-Posting-Host: castor.informatik.med.uni-giessen.de +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) +X-Accept-Language: en +X-Mozilla-Status: 8000 +X-Mozilla-Status2: 00000000 + + +Hi ! + +---- + +I don't know whether this is implemented or not... + +Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? + +---- + +Bye, +Roland + +-- + __ . . __ + (o.\ \/ /.o) Roland Mainz C programmer + \__\/\/__/ Roland.Mainz@informatik.med.uni-giessen.de MPEG specialist + /O /==\ O\ gisburn@w-specht.rhein-ruhr.de Sun&&Amiga programmer + (;O/ \/ \O;) TEL +49 (0) 2426901568 FAX +49 (0) 2426901569 + + + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Alec Flett +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Tue, 08 Jun 1999 16:12:50 -0700 +Organization: Another Netscape Collabra Server User +Lines: 17 +Message-ID: <375DA372.15BA02CC@netscape.com> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> +NNTP-Posting-Host: h-208-12-40-101.netscape.com +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.3 i686) +X-Accept-Language: English, en +To: Roland Mainz +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + +Roland Mainz wrote: + +> Hi ! +> +> ---- +> +> I don't know whether this is implemented or not... +> +> Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? +> + +Hmm... my gut is telling me that nobody from Netscape will be working on this....but I'm +quite sure that if someone does feel like adding this functionality, many unix mail people +would be very pleased... + + Alec + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Roland Mainz +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Wed, 09 Jun 1999 01:29:29 +0200 +Organization: Another Netscape Collabra Server User +Lines: 39 +Message-ID: <375DA759.4687D7AE@informatik.med.uni-giessen.de> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> <375DA372.15BA02CC@netscape.com> +NNTP-Posting-Host: castor.informatik.med.uni-giessen.de +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) +X-Accept-Language: en +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + + +Hi ! + +---- + +Alec Flett wrote: + +> > I don't know whether this is implemented or not... +> > +> > Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? +> > +> +> Hmm... my gut is telling me that nobody from Netscape will be working on this....but I'm +> quite sure that if someone does feel like adding this functionality, many unix mail people +> would be very pleased... + +Question(s): +- What must/should be implemented to get this working (maybe a list of parts which must + be implemented) ? + Our current way is to use a POP3 server for Mozilla. The idea would be to strip-down + the pop3-server code, strip-down the Mozilla5-pop3-client code and connect both code + pieces at their ends. Sound simple (in theory), does it (in real world) ? +- Does Mozilla 4.x implement local Unix mail ? +- Does Solaris 2.7 implement a genereric mail access support API for this ? + +---- + +Bye, +Roland + +-- + __ . . __ + (o.\ \/ /.o) Roland Mainz C programmer + \__\/\/__/ Roland.Mainz@informatik.med.uni-giessen.de MPEG specialist + /O /==\ O\ gisburn@w-specht.rhein-ruhr.de Sun&&Amiga programmer + (;O/ \/ \O;) TEL +49 (0) 2426901568 FAX +49 (0) 2426901569 + + + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Alec Flett +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Tue, 08 Jun 1999 17:46:25 -0700 +Organization: Another Netscape Collabra Server User +Lines: 60 +Message-ID: <375DB961.86D7518B@netscape.com> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> <375DA372.15BA02CC@netscape.com> <375DA759.4687D7AE@informatik.med.uni-giessen.de> +NNTP-Posting-Host: h-208-12-40-101.netscape.com +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.3 i686) +X-Accept-Language: English, en +To: Roland Mainz +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + +Roland Mainz wrote: + +> Hi ! +> +> ---- +> +> Alec Flett wrote: +> +> > > I don't know whether this is implemented or not... +> > > +> > > Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? +> > > +> > +> > Hmm... my gut is telling me that nobody from Netscape will be working on this....but I'm +> > quite sure that if someone does feel like adding this functionality, many unix mail people +> > would be very pleased... +> +> Question(s): +> - What must/should be implemented to get this working (maybe a list of parts which must +> be implemented) ? +> Our current way is to use a POP3 server for Mozilla. The idea would be to strip-down +> the pop3-server code, strip-down the Mozilla5-pop3-client code and connect both code +> pieces at their ends. Sound simple (in theory), does it (in real world) ? + +(I'm going to start calling Unix Mail "movemail" because we've called it that in past versions +of the product) + +It's actually probably simpler than your description - we've done a fairly good job at keeping +the idea of POP (as a protocol for retrieving remote mail) and Local Mail (as a way of storing +mail messages locally) as seperate entities, though there is still work to be done to seperate +the two. Both implementations reside in mozilla/mailnews/local though. + +the movemail implementation could leverage the Local Mail work, performing the same function as +POP is today. Ideally, Local Mail would not be aware of any protocol specifics, so that Pop3 +and movemail are both first class mail protocols. + +Scott or Scott could go into more specifics. + +If you're interested in helping us, the first thing to do would be to try to break local mail +apart from POP in a way that POP is just one more pluggable mail protocol that stores mail in +Local Mail....if you submit patches, I'll be more than happy to review them and check them +in... + +> +> - Does Mozilla 4.x implement local Unix mail ? + +Yes, but the code is VERY different than our current codebase, it's fairly simple, and wouldn't +really be worth the effort of bringing it over + +> +> - Does Solaris 2.7 implement a genereric mail access support API for this ? +> + +No, unfortunately not...and even if it did, there's no cross-Unix API so I wouldn't want us to +be tied to one particular unix. + + Alec + + + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Akkana Peck +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Tue, 08 Jun 1999 18:43:56 -0700 +Organization: Another Netscape Collabra Server User +Lines: 37 +Message-ID: <375DC6DC.815E9790@netscape.com> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> <375DA372.15BA02CC@netscape.com> <375DA759.4687D7AE@informatik.med.uni-giessen.de> +NNTP-Posting-Host: h-208-12-38-95.netscape.com +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.6 i686) +X-Accept-Language: en +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + +> > > Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? + +> Alec Flett wrote: +> > Hmm... my gut is telling me that nobody from Netscape will be working on this....but I'm +> > quite sure that if someone does feel like adding this functionality, many unix mail people +> > would be very pleased... + +Roland Mainz wrote: +> Question(s): +> - What must/should be implemented to get this working (maybe a list of parts which must +> be implemented) ? +> Our current way is to use a POP3 server for Mozilla. The idea would be to strip-down +> the pop3-server code, strip-down the Mozilla5-pop3-client code and connect both code +> pieces at their ends. Sound simple (in theory), does it (in real world) ? +> - Does Mozilla 4.x implement local Unix mail ? +> - Does Solaris 2.7 implement a genereric mail access support API for this ? + +Seems like it should be easier than that. /var/mail/username (or +whatever) is just a Berkeley mail folder, which we already support. +Seems to me that if you did two things: + +1. Make the inbox folder name, not just the directory it lives in +(mail.server.server1.directory) configurable, so you can say "the inbox +file is [file name]" instead of "the inbox file is [directory +name]/Inbox" the way it does now. (Alternately, I suppose users could +just symlink /var/mail/`whoami` to ~/mozillamail/Inbox or wherever ...) + +2. Change the periodic mail download so that instead of polling the POP +or IMAP server, it just refreshes from the inbox folder. I haven't +looked into the biff code in 5.0 (if it's there yet) so I don't know +how configurable this is. + +Is there something else here that's tricky? I never understood why we +had all that movemail stuff in 4.x when we already supported Berkeley +mail files. + + ...Akkana +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Roland Mainz +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Wed, 09 Jun 1999 16:56:11 +0200 +Organization: Another Netscape Collabra Server User +Lines: 30 +Message-ID: <375E808B.C3A02DE0@informatik.med.uni-giessen.de> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> <375DA372.15BA02CC@netscape.com> <375DA759.4687D7AE@informatik.med.uni-giessen.de> <375DC6DC.815E9790@netscape.com> +NNTP-Posting-Host: castor.informatik.med.uni-giessen.de +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) +X-Accept-Language: en +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + + +Hi ! + +---- + +Akkana Peck wrote: + +> > > > Is it planned that Mozilla 5 implements support for local Unix mail (e.g. /var/mail/) ? +> +> Seems like it should be easier than that. /var/mail/username (or +> whatever) is just a Berkeley mail folder, which we already support. +> Seems to me that if you did two things: + +I filed Bugzilla (Mail/news) bug 7836 (feature request) to track this idea (and to get this +feature implemented in the mail/news-prefs dialog). + +---- + +Bye, +Roland + +-- + __ . . __ + (o.\ \/ /.o) Roland Mainz C programmer + \__\/\/__/ Roland.Mainz@informatik.med.uni-giessen.de MPEG specialist + /O /==\ O\ gisburn@w-specht.rhein-ruhr.de Sun&&Amiga programmer + (;O/ \/ \O;) TEL +49 (0) 2426901568 FAX +49 (0) 2426901569 + + + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Alec Flett +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Wed, 09 Jun 1999 18:06:42 -0700 +Organization: Another Netscape Collabra Server User +Lines: 63 +Message-ID: <375F0FA2.EF7EC89D@netscape.com> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> <375DA372.15BA02CC@netscape.com> <375DA759.4687D7AE@informatik.med.uni-giessen.de> <375DC6DC.815E9790@netscape.com> +NNTP-Posting-Host: h-208-12-40-101.netscape.com +Mime-Version: 1.0 +Content-Type: multipart/mixed; + boundary="------------63474AC20714B91F1D656D9C" +X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.3 i686) +X-Accept-Language: English, en +To: Akkana Peck +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + +This is a multi-part message in MIME format. +--------------63474AC20714B91F1D656D9C +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit + +Akkana Peck wrote: + +> +> Is there something else here that's tricky? I never understood why we +> had all that movemail stuff in 4.x when we already supported Berkeley +> mail files. + +I think one of the main reasons for this is because it's kind of good e-mail karma to move your +mail OUT of /var/mail and put it in your own directory. I think this is what other unixmail +clients do.... + +The other issue is that metadata is kept about each mailbox file - what messages are unread, the +sorting order, the character set, etc... We do this normally by keeping a .msf file with the same +name as the directory at the same level as this directory. This means that if I try to point my +inbox at /var/mail/alecf, messenger will want to create a file /var/mail/alecf.msf + +It would likely be difficult to change this, because bits of our architecture depend on in + +...our architecture also depends on the folder hierarchy matching a directory structure on +disk...meaning that if I have, in messenger: + +Local Mail + +- INBOX + +- My Folder + +- Another Folder + +The assumption is that INBOX is a sibling of My Folder on disk, and that Another Folder is a +mailbox inside the directory My Folder.sbd (since My Folder is already a file, not a +subdirectory). This means that My Folder would go into /var/mail/My Folder and Another Folder +would go in /var/mail/My Folder.sbd/AnotherFolder + +it would be alot of overhead to try and abstract this so that each folder's location is +independant of it's position in messenger's hierarchy. I think this overhead is not worth the +minimal gain in capability. + + Alec + +--------------63474AC20714B91F1D656D9C +Content-Type: text/x-vcard; charset=us-ascii; + name="alecf.vcf" +Content-Transfer-Encoding: 7bit +Content-Description: Card for Alec Flett +Content-Disposition: attachment; + filename="alecf.vcf" + +begin:vcard +n:Flett;Alec +x-mozilla-html:FALSE +org:Netscape Communications;Unix Mail and News Client +adr:;;;;;; +version:2.1 +email;internet:alecf@netscape.com +x-mozilla-cpt:;0 +fn:Alec Flett +end:vcard + +--------------63474AC20714B91F1D656D9C-- + +From - Thu Jun 17 00:59:57 1999 +Path: secnews.netscape.com!not-for-mail +From: Seth Spitzer +Newsgroups: netscape.public.mozilla.mail-news +Subject: Re: Request for implementation: Support for Unix local mail +Date: Thu, 17 Jun 1999 00:54:41 -0700 +Organization: Another Netscape Collabra Server User +Lines: 81 +Message-ID: <3768A9C1.DD81537D@netscape.com> +References: <375D61D1.B3CD128F@informatik.med.uni-giessen.de> <375DA372.15BA02CC@netscape.com> <375DA759.4687D7AE@informatik.med.uni-giessen.de> <375DC6DC.815E9790@netscape.com> <375F0FA2.EF7EC89D@netscape.com> +NNTP-Posting-Host: h-205-217-240-69.netscape.com +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.0.36 i686) +X-Accept-Language: en +X-Mozilla-Status: 8010 +X-Mozilla-Status2: 00000000 + +Alec, + +> > Is there something else here that's tricky? I never understood why we +> > had all that movemail stuff in 4.x when we already supported Berkeley +> > mail files. +> +> I think one of the main reasons for this is because it's kind of good e-mail karma to move your +> mail OUT of /var/mail and put it in your own directory. I think this is what other unixmail +> clients do.... + +I just looked at the movemail code from 4.x and alec is right. + +ns/cmd/xfe/movemail.c basically did this: + +lock /var/spool/mail/$USERNAME +copy /var/spool/mail/$USERNAME to .netscape.mail-recovery +call MSG_IncorporateFromFile() with .netscape.mail-recovery + +I'm leaving out the gory file locking details and the builtin vs +external movemail stuff. + +movemail in 5.0 is like pop, but you can't leave mail on the "server", +and the "server" is really your spool file. + +> The other issue is that metadata is kept about each mailbox file - what messages are unread, the +> sorting order, the character set, etc... We do this normally by keeping a .msf file with the same +> name as the directory at the same level as this directory. This means that if I try to point my +> inbox at /var/mail/alecf, messenger will want to create a file /var/mail/alecf.msf +> +> It would likely be difficult to change this, because bits of our architecture depend on in +> +> ...our architecture also depends on the folder hierarchy matching a directory structure on +> disk...meaning that if I have, in messenger: +> +> Local Mail +> +- INBOX +> +- My Folder +> +- Another Folder +> +> The assumption is that INBOX is a sibling of My Folder on disk, and that Another Folder is a +> mailbox inside the directory My Folder.sbd (since My Folder is already a file, not a +> subdirectory). This means that My Folder would go into /var/mail/My Folder and Another Folder +> would go in /var/mail/My Folder.sbd/AnotherFolder +> +> it would be alot of overhead to try and abstract this so that each folder's location is +> independant of it's position in messenger's hierarchy. I think this overhead is not worth the +> minimal gain in capability. + +we have ~/ImapMail, ~/Mail, ~/News, we could have ~/MoveMail + +Its all berkeley style mail boxes, and when we process the +.netscape.mail-recovery file, it writes into ~/MoveMail/Inbox (like what +pop does to ~/Mail/Inbox) + +in 5.0 you could have multiple imap, multiple pop, and local UNIX mail +all at the same time. + +How about them apples? + +I've sanitizing the spence's old ns/cmd/xfe/movemail.c code now. I'll +bring it over into the 5.0 tree, and start up a +mozilla/mailnews/movemail directory. + +One thing: alecf and I (the UNIX people on 5.0 mail / news) will +probably not have time to implement movemail for 5.0 + +It would be so cool if someone out there wanted to take this on for 5.0. + +Think about it: + + movemail users will love you + your peers will admire you + free mozilla t-shirts (I'll make sure you get some) + +I'm adding adding this task to http://www.mozilla.org/mailnews/jobs.html +right now. + +-Seth +-- +Seth Spitzer +http://people.netscape.com/sspitzer about:sspitzer diff --git a/mailnews/movemail/src/movemail.c b/mailnews/movemail/src/movemail.c new file mode 100644 index 000000000000..591b4d88c9fa --- /dev/null +++ b/mailnews/movemail/src/movemail.c @@ -0,0 +1,360 @@ +/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- + * + * The contents of this file are subject to the Netscape Public License + * Version 1.0 (the "NPL"); you may not use this file except in + * compliance with the NPL. You may obtain a copy of the NPL at + * http://www.mozilla.org/NPL/ + * + * Software distributed under the NPL is distributed on an "AS IS" basis, + * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the NPL + * for the specific language governing rights and limitations under the + * NPL. + * + * The Initial Developer of this code under the NPL is Netscape + * Communications Corporation. Portions created by Netscape are + * Copyright (C) 1999 Netscape Communications Corporation. All Rights + * Reserved. + * + * movemail.c --- move mail between folders with file locking + * Originally Created by Spencer Murray , 15-Sep-95. + */ + +#include +#include +#include +#include +#include +#include +#include + +typedef int XP_Bool; + +#define TRUE 1 +#define FALSE 0 + +#define LINUX_GLIBC_2 + +#include +#if !defined(__FreeBSD__) && !defined(MACLINUX) && !defined(LINUX_GLIBC_2) +extern char *sys_errlist[]; +extern int sys_nerr; +#endif + +#if 0 +/* for XP_GetString() */ +#include +#endif +int XFE_CANT_MOVE_MAIL = 0; +int XFE_CANT_GET_NEW_MAIL_LOCK_FILE_EXISTS = 0; +int XFE_CANT_GET_NEW_MAIL_UNABLE_TO_CREATE_LOCK_FILE = 0; +int XFE_CANT_GET_NEW_MAIL_SYSTEM_ERROR = 0; +int XFE_CANT_MOVE_MAIL_UNABLE_TO_OPEN = 0; +int XFE_CANT_MOVE_MAIL_UNABLE_TO_READ = 0; +int XFE_CANT_MOVE_MAIL_UNABLE_TO_WRITE = 0; +int XFE_THERE_WERE_PROBLEMS_MOVING_MAIL = 0; +int XFE_THERE_WERE_PROBLEMS_MOVING_MAIL_EXIT_STATUS = 0; +int XFE_THERE_WERE_PROBLEMS_CLEANING_UP = 0; +int XFE_MOVEMAIL_FAILURE_SUFFIX = 0; +int XFE_UNKNOWN_ERROR_CODE = 0; +int XFE_MOVEMAIL_NO_MESSAGES = 0; +int XFE_MOVEMAIL_CANT_DELETE_LOCK = 0; + +#define TMP_SUFFIX ".nslock" +#define LOCK_SUFFIX ".lock" + +#define NAME_LEN 1024 + +#ifndef BUFSIZ +#define BUFSIZ 1024 +#endif /* BUFSIZ */ + +char *XP_GetString(int i) { + return NULL; +} + +static void +fe_movemail_perror(const char *message) +{ + int e = errno; + char *es = 0; + char *buf1 = 0; + char buf2[512]; + char *suffix; + int L; + + if ((unsigned)e < (unsigned)sys_nerr) + { + es = sys_errlist [e]; + } + else + { + snprintf (buf2, sizeof (buf2), XP_GetString( XFE_UNKNOWN_ERROR_CODE ), + errno); + printf("XFE_UNKNOWN_ERROR_CODE\n"); + es = buf2; + } + + suffix = XP_GetString(XFE_MOVEMAIL_FAILURE_SUFFIX); + printf("XFE_MOVEMAIL_FAILURE_SUFFIX\n"); + if(!suffix) suffix = ""; + if(!message) message = ""; + L = strlen(message) + strlen(es) + strlen(suffix) + 40; + buf1 = (char *) malloc(L); + if(!buf1) return; + snprintf (buf1, L-1, "%s\n%s\n\n%s", message, es, suffix); +#if 0 + FE_Alert (buf1); +#endif + free(buf1); +} + + +int +fe_MoveMail (char *from, char *to) +{ + XP_Bool succeeded = FALSE; + char tmp_file[NAME_LEN]; + char lock_file[NAME_LEN]; + char spool_dir[NAME_LEN]; + char *bp, buf[BUFSIZ]; + char msgbuf[1024]; + int from_fd = -1; + int to_fd = -1; + int tmp_fd = -1; + int nread, nwritten, nbytes, ntodo; + struct stat st; + + *lock_file = 0; + + if (!from || !to) + return FALSE; + + if (strlen(from) > NAME_LEN - 1) return FALSE; + + /* Make spool_dir be "/var/spool/mail" from "/var/spool/mail/$USER". */ + strcpy(spool_dir, from); + while ((bp = strrchr(spool_dir, '/')) && bp[1] == '\0') + *bp = '\0'; + if (!bp) return FALSE; + *bp = 0; + + printf("%s\n", spool_dir); + + /* If we can't write into the directory itself, we can't create files, + so we lose. */ + if (access(spool_dir, R_OK|W_OK) < 0) + { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString(XFE_CANT_MOVE_MAIL_UNABLE_TO_WRITE), + from); + printf("XFE_CANT_MOVE_MAIL_UNABLE_TO_WRITE\n"); + fe_movemail_perror(msgbuf); + goto FAIL; + } + + /* If the mail-spool file doesn't exist, or is 0-length, bug out. + */ + if (stat(from, &st) < 0 || + st.st_size == 0) + { +#if 0 + NET_Progress (XP_GetString(XFE_MOVEMAIL_NO_MESSAGES)); +#endif + goto FAIL; + } + + snprintf(tmp_file, sizeof (tmp_file), "%s%s", from, TMP_SUFFIX); + + if (access(tmp_file, 0) == 0) { + /* The tmp file exists; try to get rid of it */ + + if (unlink(tmp_file) < 0) { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_CANT_GET_NEW_MAIL_LOCK_FILE_EXISTS ), + tmp_file); + fe_movemail_perror(msgbuf); + goto FAIL; + } + } + + snprintf(lock_file, sizeof (lock_file), "%s%s", from, LOCK_SUFFIX); + + while (1) { + int ret; + + /* First create a real file, $USER.nslock + */ + tmp_fd = open(tmp_file, O_WRONLY|O_CREAT|O_EXCL, 0666); + + if (tmp_fd < 0) { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_CANT_GET_NEW_MAIL_UNABLE_TO_CREATE_LOCK_FILE ), + tmp_file); + fe_movemail_perror(msgbuf); + goto FAIL; + } + close(tmp_fd); + tmp_fd = -1; + + /* Then make a hard link from $USER.lock to $USER.nslock -- this is the + trick to make NFS behave synchronously. + */ + ret = link(tmp_file, lock_file); + + /* Now we've (attempted to) make the link. `ret' says whether it was + successful. It would have failed if the lock was already being held. + + Regardless of whether it succeeded, we can now delete $USER.nslock + (the thing to which the hard-link points.) + */ + if (unlink(tmp_file) < 0) { + snprintf(msgbuf, sizeof (msgbuf), + /* This error message isn't quite right; what it really + means is "can't delete $MAIL.nslock", but I guess that + could only happen if some other user was the owner of + it? Or if it was already gone? Weird... */ + XP_GetString(XFE_MOVEMAIL_CANT_DELETE_LOCK), tmp_file); + printf("XFE_MOVEMAIL_CANT_DELETE_LOCK\n"); + fe_movemail_perror(msgbuf); + goto FAIL; + } + + /* If we didn't obtain the lock (== make the hard-link), above, then + retry getting it until the file is 60 seconds old... Then get + Guido to go over and bust its kneecaps. + */ + if (ret < 0) { + sleep (1); + if (stat(lock_file, &st) >= 0) { + int current = time(NULL); + if (st.st_ctime < current - 60) + unlink (lock_file); + } + } else { + /* Got the lock - done waiting. */ + break; + } + } + + /* All of this junk used to happen in a forked process, but that's not + necessary any more (actually, hasn't been for a long time) since we + no longer play any setuid/setgid games -- there is no gain to doing + this in another fork and waiting for it to complete. + */ + + /* Open the mail spool file for input... + */ + from_fd = open(from, O_RDWR, 0666); + if (from_fd < 0) + { + int err; + if (access(from, W_OK) < 0) /* look again, for right error message */ + err = XFE_CANT_MOVE_MAIL_UNABLE_TO_WRITE; + else if (access(from, 0) == 0) + err = XFE_CANT_MOVE_MAIL_UNABLE_TO_READ; + else + err = XFE_CANT_MOVE_MAIL_UNABLE_TO_OPEN; + snprintf(msgbuf, sizeof (msgbuf), XP_GetString(err), from); + fe_movemail_perror(msgbuf); + goto FAIL; + } + + /* Open the destination file for output... + */ + to_fd = open(to, O_WRONLY|O_CREAT|O_EXCL, 0666); + if (to_fd < 0) { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_CANT_MOVE_MAIL_UNABLE_TO_OPEN ), + to); + fe_movemail_perror(msgbuf); + goto FAIL; + } + + /* copy the file */ + + nbytes = BUFSIZ; + + while (1) { + nread = read(from_fd, buf, nbytes); + + if (nread < 0) { + /* we're busted */ + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_CANT_MOVE_MAIL_UNABLE_TO_READ ), from); + fe_movemail_perror(msgbuf); + goto FAIL; + } + + if (!nread) { + /* we're done */ + break; + } + + for (ntodo = nread, bp = buf; + ntodo > 0; + ntodo -= nwritten, bp += nwritten) { + nwritten = write(to_fd, bp, ntodo); + + if (nwritten < 0) { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_CANT_MOVE_MAIL_UNABLE_TO_WRITE ), to); + fe_movemail_perror(msgbuf); + goto FAIL; + } + } + } + + /* if we made it this far, we're done copying the file contents. + First, close and sync the output file. + */ + + if (fsync(to_fd) < 0 || + close(to_fd) < 0) + { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_CANT_MOVE_MAIL_UNABLE_TO_WRITE ), to); + fe_movemail_perror(msgbuf); + goto FAIL; + } + to_fd = -1; + + /* Now the output file is closed and sync'ed, so we can truncate the + spool file. + */ + if (ftruncate(from_fd, (off_t)0) < 0) + { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_THERE_WERE_PROBLEMS_CLEANING_UP ), + from); + fe_movemail_perror(msgbuf); + goto FAIL; + } + + succeeded = TRUE; + + FAIL: + + if (to_fd >= 0) close(to_fd); + if (from_fd >= 0) close(from_fd); + if (tmp_fd >= 0) close(tmp_fd); + + /* Unlink the lock file. + If this fails, but we were otherwise successful, then whine about it. + Otherwise, we've already presented an error dialog about something else. + */ + if (*lock_file && unlink(lock_file) < 0 && succeeded) + { + snprintf(msgbuf, sizeof (msgbuf), + XP_GetString( XFE_THERE_WERE_PROBLEMS_CLEANING_UP ), + lock_file); + fe_movemail_perror(msgbuf); + succeeded = FALSE; + } + + return succeeded; +} + +main() +{ + fe_MoveMail ("/var/spool/mail/localguy","/home/localguy/mozilla.mail-recovery"); +}