Date: Wed, 18 Nov 1998 12:21:00 -0500
From: "Michael J. Vinca" <mjv2411 at ritvax.isc.rit dot edu>
Subject: Re: Files for Subscribing are Filtered
Oops, I forgot to add that the person actually is subscribed, they just
don't get any mail telling them so. I could write the CGI so I send out
another mailing, but I would rather Autoshare send out the same mailing
as if they actually sent the subscription request.
"Michael J. Vinca" wrote:
> When Autoshare Processes this file, it will say "b2776c3e - not
> processed (Filter Applied)"
>
> I have set res #201 string 23 to both 0 and 1 and this doesn't seem to help.
> (I switched it using remote admin and then issuing a run command afterward)
>
> There are no files in my Filters folder.
>
> What am I doing wrong?
>
> Michael J. Vinca
Date: Thu, 19 Nov 1998 07:34:18 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Files for Subscribing are Filtered
At 12:21 -0500 11/18/98, Michael J. Vinca wrote:
> Oops, I forgot to add that the person actually is subscribed, they just
> don't get any mail telling them so. I could write the CGI so I send out
> another mailing, but I would rather Autoshare send out the same mailing
> as if they actually sent the subscription request.
If you use the File Mail AppleScript command, a message file is put in the
Filed Mail folder as if a normal request had taken place via the mail
server.
tell application "AutoShare"
File Mail Email "a@b" Name "a b" Command "subscribe fun-l"
end tell
Date: Thu, 19 Nov 1998 06:13:56 -0800
From: Mark Hartman <mh-list at harthaven dot com>
Subject: Re: Files for Subscribing are Filtered
At 3:14 PM -0800 11/17/1998, Michael J. Vinca wrote:
>Because of the use of labs here at RIT, people do not use Web-browsers
>that are configured to their e-mail addresses. As a result I wrote a
>CGI that asks for their address and what they want to do, creates an
>e-mail for them, and places it in the Filed Mail folder. The
>Applescript commands is as follows:
>
>tell application "AutoShare" to ¬
> Send Mail To {Email:to_address, Ename:"List Server"} From
>{Email:from_address, Ename:"Web Poster"} ¬
> Subject "Web Post" Body File ¬
> (docsPath & "lists$cgi$temp.txt") Precedence "bulk"
In my CGI, I instead use:
tell application "AutoShare" to ¬
File Mail Email emailArg Name usernameArg Command emc
which seems to tell AutoShare to create a properly formatted _incoming_
e-mail message. The "Send Mail" command looks like it tries to create
an _outgoing_ mail message, and thus the "bulk" precedence is applied.
This seems to work in all cases, including the triggering of mailback
processing.
HTH.
Date: Sun, 22 Nov 1998 22:47:32 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: No list server is an island...
Well, why not make the web archives searchable? That's what I somehow came
to ask myself once I had digested a recent thread on web server tests
dealing with throughput versus speed. If speed is what is important to the
browsing user, then a CGI in particular needs to be on its toes, so I
decided to make searching the archives faster, to optionally search in the
automated web archives and to write a web form and a CGI sample to
illustrate this.
To have a mail server, a web server, AppleScripts and/or third-party
utilities run along with your list server may not be for everyone. It's a
hassle when it doesn't work, but it's nice when it does. And autoshare2.cgi
worked for me once I had fiddled around with it for a while. Having the
AutoShare server do a raw search of a 374K archive folder and return a list
of hits to an AppleScript CGI in six seconds is alright, and when the CGI
doesn't have to do much else from time the web browser request arrives
until the time a value is returned, it isn't all that bad.
It's up to you how much polish is to be added to the AppleScript server
application that is often referred to the primary bottleneck, but it
shouldn't be much more than formatting the list of hits into a return
value, which the sample also does. And if you get stuck, be sure to save
time by taking the time to put the core code into a regular compiled script
to more easily target potential errors.
The web form and the CGI sample are in the 3.0.3b2 archive.
Date: Mon, 23 Nov 1998 12:12:06 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: handle CGI request
As both autoshare.cgi (list subscriptions) and autoshare2.cgi (archive
searches) use WWW‡sdoc as the main handler command, it may be noted that=
WWW‡sdoc appears as handle CGI request in the AppleScript dictionary of Ma=
c
OS 8.5's scripting addition entitled Standard Additions.
Date: Mon, 23 Nov 1998 16:41:55 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Big Files are killing Autoshare
I'm currently experiencing constant crashing of Autoshare when large files
are attempted to be posted on a list. The lists are setup to prevent the
large files from being distributed, of course, but there's nothing I can do
to prevent someone from trying. The problem is, when they try, Autoshare
just quits. It attempts to process the file, but after about 3 minutes, it
just dies.
Unless I'm in here watching, or notice unusually low mailing list traffic,
there's no way for me to know. Is there anything I can change on my end to
prevent Autoshare from dying like this? Or is there anything that you can
do to change Autoshare to handle it better?
The size of the files are 2.1M and 4.3M respectively, and I'm running
Autoshare 3.0.1.
Thanks,
Bill
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Mon, 23 Nov 1998 20:24:52 -0500
Subject: Re: Big Files are killing Autoshare
From: "William J. Suarez" <wsuarez at netsilicon dot com>
Bill,
I've seen this before as well. Increase the memory partition for AutoShare
to something around 4Megs and see if you still have the problem.
Regards,
Bill Suarez
----------
>From: Camelot Administrator <camelot.admin at lmco dot com>
>To: autoshare-talk at frutiger.staffs.ac dot uk (Subscribers of AutoShare-Talk)
>Subject: Big Files are killing Autoshare
>Date: Mon, Nov 23, 1998, 6:41 PM
>
>I'm currently experiencing constant crashing of Autoshare when large files
>are attempted to be posted on a list. The lists are setup to prevent the
>large files from being distributed, of course, but there's nothing I can do
>to prevent someone from trying. The problem is, when they try, Autoshare
>just quits. It attempts to process the file, but after about 3 minutes, it
>just dies.
>
>Unless I'm in here watching, or notice unusually low mailing list traffic,
>there's no way for me to know. Is there anything I can change on my end to
>prevent Autoshare from dying like this? Or is there anything that you can
>do to change Autoshare to handle it better?
>
>The size of the files are 2.1M and 4.3M respectively, and I'm running
>Autoshare 3.0.1.
>
>Thanks,
>Bill
>+----------------------------------------------------------------+
>| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
>| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
>+----------------------------------------------------------------+
>
>** The AutoShare-Talk archives are at:
>** <http://frutiger.staffs.ac.uk/autoshare/archives/>
Date: Tue, 24 Nov 1998 01:22:05 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Big Files are killing Autoshare
At 16:41 -0700 11/23/98, Camelot Administrator wrote:
> I'm currently experiencing constant crashing of Autoshare when large files
> are attempted to be posted on a list. The lists are setup to prevent the
> large files from being distributed, of course, but there's nothing I can do
> to prevent someone from trying. The problem is, when they try, Autoshare
> just quits. It attempts to process the file, but after about 3 minutes, it
> just dies.
Are you sure? I have never come across that. But it's slow alright with
those mega attachments. Try adding the letter K to the List Stuff field,
which removes the attachment at an early stage. Still slow, but faster
though.
Date: Tue, 24 Nov 1998 08:31:59 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Re: Big Files are killing Autoshare
At 1:22 AM -0800 on 11/24/98, Mikael Hansen wrote:
> At 16:41 -0700 11/23/98, Camelot Administrator wrote:
>
> > I'm currently experiencing constant crashing of Autoshare when large files
> > are attempted to be posted on a list. The lists are setup to prevent the
> > large files from being distributed, of course, but there's nothing I can do
> > to prevent someone from trying. The problem is, when they try, Autoshare
> > just quits. It attempts to process the file, but after about 3 minutes, it
> > just dies.
>
> Are you sure? I have never come across that. But it's slow alright with
> those mega attachments. Try adding the letter K to the List Stuff field,
> which removes the attachment at an early stage. Still slow, but faster
> though.
>
As a test, I just tried it again. I sent a file which resulted in a 2.9
Meg attachment to a list which is set to reject large files. The file made
it through EIMS, and got into the Filed Mail folder in Autoshare. The
Autoshare window said it was processing it, and after processing for a
couple of minutes, the Autoshare application crashed error 10. Sometimes
it gives the error message, sometimes it just crashes with no error
message, but it _always_ crashes when a file of this size gets received.
I put the K in the list stuff field and tried again. Made no difference.
This time I timed the event and got a more accurate time on how long it
takes to die. It took about 4 minutes and 13 seconds to die on a 2.9 meg
file.
Would you like me to send the file to this Autoshare list to see if I can
kill the Autoshare running this list? ;)
Seriously, now what?
Bill
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Tue, 24 Nov 1998 08:51:58 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Re: Big Files are killing Autoshare
At 8:24 PM -0500 on 11/23/98, William J. Suarez wrote:
> Bill,
>
> I've seen this before as well. Increase the memory partition for AutoShare
> to something around 4Megs and see if you still have the problem.
>
I upped the memory partition for Autoshare to 4 meg, and it still died (but
I wouldn't have wanted that to be the solution anyway!).
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
From: "Suarez, William" <WSuarez at netsilicon dot com>
Subject: RE: Big Files are killing Autoshare
Date: Tue, 24 Nov 1998 11:58:39 -0500
Interesting, I've had no failures at all since I bumped up the memory
partition and I've sent through some "nasty" attachments.
Is it the same attachment each time that kills it or will any large
attachment do it?
-----Original Message-----
From: Camelot Administrator [mailto:camelot.admin at lmco dot com]
Sent: Tuesday, November 24, 1998 10:52 AM
To: autoshare-talk at frutiger.staffs.ac dot uk
Subject: Re: Big Files are killing Autoshare
At 8:24 PM -0500 on 11/23/98, William J. Suarez wrote:
> Bill,
>
> I've seen this before as well. Increase the memory partition for AutoShare
> to something around 4Megs and see if you still have the problem.
>
I upped the memory partition for Autoshare to 4 meg, and it still died (but
I wouldn't have wanted that to be the solution anyway!).
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
** The AutoShare-Talk archives are at:
** <http://frutiger.staffs.ac.uk/autoshare/archives/>
Date: Tue, 24 Nov 1998 13:43:07 -0500
From: "Christopher T. Payne" <CTPayne at lbl dot gov>
Subject: Error-To: problem
Hi. I'm a new AutoShare user, using it primarily to offer a good vacation
reply feature to clients of my EIMS 2.2 mail server. I've looked for
coverage of this in the docs, but haven't found anything. Can someone point
me in the right direction?
The problem: I receive bounced mail as the postmaster of the AutoShare
system. I'm getting mail that looks like the following:
Error-To:
CTPayne at mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail dot dc.
mail.dc.mail.dc.mail.dc.mail.dc.mail.dc
Obviously, the domain on that header isn't being fully resolved. I can't
seem to find anyplace where such information would be located, though, so I
don't know how I can change it to provide the correct information.
Also, on a somewhat related note, I notice that the automatic replies are
going out using the client's local mail address, not a more "official"
generic address. For example, I'd prefer to have "user@domain" rather than
"user@popmailserveraddress dot domain" Is there any way I can adjust this in
AutoShare, so that the "Reply To" appears different from the "From:"?
Thanks.
-CTP
-------------------------------------
Christopher Payne
Lawrence Berkeley National Laboratory
Suite 500
1250 Maryland Avenue, SW
Washington, DC 20024
(202) 484-0884 x105
(202) 484-0888 (fax)
http://www.dc.lbl.gov/payne
Date: Tue, 24 Nov 1998 13:50:22 -0500
Subject: Moderated list quirk
From: "Shan Vosseller" <updates at vsarts dot org>
I have a list setup for moderated and have a precedence question. When a
subscriber posts to the list, it routes to the list moderator (who in this
case is different from the general list server admin). The moderator
redirects the message to the listname at lists.domain dot com address. However, it
is filtered out automatically because the precedence is set to bulk in the
original message to the moderator. The redirection of the message doesn't
change the precedence. However, NEW messages generated by the moderator are
sent to the list fine.
Is there something I can configure to change this behavior?
-Shan
Date: Tue, 24 Nov 1998 21:32:22 +0000
From: Michael Hambly <michael at mayo-ireland dot ie>
Subject: AutoShare 3.02 stuck in loop?
AutoShare 3.02 stuck?
Status window is showing:
'Updating archives for list'
but I can't close down or make any menu choices, other programs on the
computer are working as normal. Autoshare is updating 'Time since run'.
I don't want to have to restart server but I can't force quit with TB2
Ideas?
Michael
* * * * * *
http://www.mayo-ireland.ie/ for sites on Ireland.
Researching your roots? http://mail.mayo-ireland.ie/webx?
Looking for a chat? http://chat.in-ireland.net/
Michael Hambly, Mayo Ireland Ltd, Claremorris, Co Mayo, Ireland
Tel: + 353 (0) 94 60209 Fax: + 353 (0) 94 60273
E-mail: michael at mayo-ireland dot ie
* * * * * *
Date: Tue, 24 Nov 1998 22:31:35 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Error-To: problem
At 13:43 -0500 11/24/98, Christopher T. Payne wrote:
> The problem: I receive bounced mail as the postmaster of the AutoShare
> system. I'm getting mail that looks like the following:
>
> Error-To:
>
> CTPayne at mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail.dc.mail.dc dot =
mail.dc.
> mail.dc.mail.dc.mail.dc.mail.dc.mail.dc
You're saying that AutoShare creates this Reply-To in outgoing
auto-responses and that you become aware of it because some of them bounce=
for some other reason? If you could send me a pair of sample files
(Stuffit'ed) from the Filed Mail and Incoming Mail folders respectively,
that would be helpful.
> Also, on a somewhat related note, I notice that the automatic replies are
> going out using the client's local mail address, not a more "official"
> generic address. For example, I'd prefer to have "user@domain" rather than
> "user@popmailserveraddress dot domain" Is there any way I can adjust this in
> AutoShare, so that the "Reply To" appears different from the "From:"?
You can do this using the /=rfcfrom auto-response token. See
Running the server
Running an auto-responder
Auto-response tokens
Date: Tue, 24 Nov 1998 22:34:01 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: AutoShare 3.02 stuck in loop?
At 21:32 +0000 11/24/98, Michael Hambly wrote:
> AutoShare 3.02 stuck?
>
> Status window is showing:
>
> 'Updating archives for list'
I haven't experienced this. Is the basic DFA/Norton okay?
Date: Tue, 24 Nov 1998 22:35:34 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Moderated list quirk
At 13:50 -0500 11/24/98, Shan Vosseller wrote:
> However, it is filtered out automatically because the precedence is set
> to bulk in the original message to the moderator. The redirection of the
> message doesn't change the precedence.
Redirection as in Eudora's Redirect? Are you sure? I just tried redirecting
a list message to myself, and the returned mail has no precedence field in
it.
Date: Wed, 25 Nov 1998 06:48:09 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Big Files are killing Autoshare
At 08:51 -0700 11/24/98, Camelot Administrator wrote:
> I upped the memory partition for Autoshare to 4 meg, and it still died
> (but I wouldn't have wanted that to be the solution anyway!).
Well, just because speed tests are fun and not because I really care about
list contributions with huge attachments, I decided to conduct some tests
using a list contribution message file with a 1.5MB MIME attachment.
Starting out with a standard configuration with no bells and whistles, the
message file took <gasp> 19:58 (mins:secs) to process (1.5MB is a lot of
baggage to carry around).
Telling the server that no more than 200 message lines are acceptable
(similar to what you originally did) brought it down to 12:41 (the
attachment was let go at some point, but it was sent to the listmaster).
I then added the letter K to the List Stuff field to drop the attachment as
soon as possible, which took 4:12.
The server can do a lot better, so I decided to go for a qualified guess at
where the ending MIME boundary is at (detaching is a somewhat not entirely
safe task anyway), which brought it down to 22 seconds. This is most likely
what you would be looking at when using the 3.0.3b3.
The fun really kicks in when you aim to reattach using the letter O in the
List Stuff field (and when it works). 39 seconds (down from 19:58).
Date: 25 Nov 98 09:31:59 -0600
From: Chuck Boody <chuck_boody at hopkins.k12.mn dot us>
Subject: Re: Autoshare beta 3.0.3b3
Reply to: Re: Autoshare beta 3.0.3b3
Autoshare3.0.3b3 is available by mail.
Send mail to
mailit at stumail.hopkins.k12.mn dot us
with the word =
Autosharebeta
in the subject line.
Those regularly using this service should note that mail to
mailit at stumail.hopkins.k12.mn dot us
with =
Autoshare
in the subject line will return a document indicating the current versions =
of autoshare that are available and how to get them.
Please contact me directly if you have any problems with this service.
Chuck Boody
Analyst/Programmer
ISD 270
=======
Date: Wed, 25 Nov 1998 18:01:33 +0000
From: James Berriman <J.R.Berriman at staffs.ac dot uk>
Subject: Autoshare beta 3.0.3b3 at dcl.co.uk
Now available at:
<mailto:AutoShare-software at dcl.co.uk?subject=AutoShare-3.0.3b3 dot sit>
( :-]) James
Date: Wed, 25 Nov 1998 23:30:38 -0500
From: Jerry Thompson <mlists at ppdirect dot com>
Subject: Re: Big Files are killing Autoshare
>At 1:22 AM -0800 on 11/24/98, Mikael Hansen wrote:
>> Are you sure? I have never come across that. But it's slow alright with
>> those mega attachments. Try adding the letter K to the List Stuff field,
>> which removes the attachment at an early stage. Still slow, but faster
>> though.
>>
>
>As a test, I just tried it again. I sent a file which resulted in a 2.9
>Meg attachment to a list which is set to reject large files. The file made
>it through EIMS, and got into the Filed Mail folder in Autoshare. The
>Autoshare window said it was processing it, and after processing for a
>couple of minutes, the Autoshare application crashed error 10. Sometimes
>it gives the error message, sometimes it just crashes with no error
>message, but it _always_ crashes when a file of this size gets received.
Wouldn't it be simpler to just change the largest email size for the list's
EIMS account to prevent this from happening?
Best Regards,
Jerry Thompson
Webmaster/MIS Director
PP List Management, Inc.
http://www.ppdirect.com/
Date: Thu, 26 Nov 1998 18:31:29 +0200
From: Robert Brenstein <rjb at rz.uni-potsdam dot de>
Subject: AutoShare Admin
I am a brand new user of AutoShare 3.0.2. I haven't actually succeeded to
get it going, yet. I followed the quick start guide. I managed to subscribe
correctly, but when I sent a post, my server crashed (turned itself off).
When I restarted it and watched, it sat forever processing the incoming
mail until it crashed again. The lookup into various files revealed that
one contains an ever repeating mail header after the actual file. Sth loops
for some reason.
Is there a reason why FaceSpan extension would not work on a WS8150 w/MacOS
7.1? It is in the extensions folder at the boot time, but AutoShare Admin
still claims in was not installed. On my desktop machine, which runs Mac
OS 7.5.3, Admin asks to look for it and accepts FaceSpan's presence in the
same folder as itself. Is it really the system version that makes a
difference or else?
Is version 2.4 of AutoShare stable? I'd try it if I have no luck with 3.
Robert
Date: Thu, 26 Nov 1998 19:24:12 +0100
From: "Serge Belleudy-d'Espinose" <sam at ijm.jussieu dot fr>
Subject: Re: AutoShare Admin
>Is there a reason why FaceSpan extension would not work on a WS8150 w/MacOS
>7.1? It is in the extensions folder at the boot time, but AutoShare Admin
>still claims in was not installed. On my desktop machine, which runs Mac
>OS 7.5.3, Admin asks to look for it and accepts FaceSpan's presence in the
>same folder as itself. Is it really the system version that makes a
>difference or else?
The FaceSpan extension do not need to be installed in the extension folder,
just leave it in the same folder than the admin.
>Is version 2.4 of AutoShare stable? I'd try it if I have no luck with 3.
It has been stable for me since even before 2.4 up to 3.03b2, but of course
your mileage varyŠ
SBE
\ Serge BELLEUDY - d'ESPINOSE | Reseau & Macintosh /
) @: sam at ijm dot jussieu dot fr -+- Institut J. Monod - Tour 43 (
/ http://www.ijm.jussieu.fr/ | 2 pl. Jussieu - 75251 Paris \
Date: Thu, 26 Nov 1998 19:25:47 +0000
From: Bill Bedford <billbpm at mousa.demon.co dot uk>
Subject: Listmembers, archives and advice
I have had a couple calls for help from listmembers about problem they are
having with downloading files from the archive folder.
The first person cannot down load any file, because of a MIME problem. This
is part of the header from the SIMS copy of the incoming file.
> To: autoshare at mousa.demon.co dot uk
> Subject: GET scalefour_list SUPPLIER.TEXT
> MIME-version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-transfer-encoding: quoted-printable
> X-Mailer: TFS Gateway /310000000/310101449/310101419/310200725/
> X-Engine: "TFS Engine Release 3.12 Build 101"
>
> GET scalefour_list SUPPLIER=2ETEXT
>
note the dot in the file name has been encoded -- autoshare returns it as
file unknown.
The second person as successfully download a file which has been zipped and
binhexed and wants to how to read it using only Microsoft tools............
and help appreciated.
Date: Thu, 26 Nov 1998 12:48:41 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: AutoShare Admin
At 18:31 +0200 11/26/98, Robert Brenstein wrote:
> I am a brand new user of AutoShare 3.0.2. I haven't actually succeeded to
> get it going, yet. I followed the quick start guide. I managed to subscribe
> correctly, but when I sent a post, my server crashed (turned itself off).
> When I restarted it and watched, it sat forever processing the incoming
> mail until it crashed again. The lookup into various files revealed that
> one contains an ever repeating mail header after the actual file. Sth loops
> for some reason.
Could you send that file (StuffIt'ed!) to me (meh at dnai dot com)? Thanks.
You probably have a corrupt preferences file or a corrupt or malformed
message file.
> Is there a reason why FaceSpan extension would not work on a WS8150
> w/MacOS 7.1?
The following quotes from the documentation may be of some help.
Getting started
Installing AutoShare
System requirements
"AutoShare runs on any Macintosh model, but does require System 7.5 or
later (for the scriptable Finder)."
Running the server
Interfaces
AutoShare Admin application
"The FaceSpan Extension is expecting to find the QuickTime and QuickTime
PowerPlug extensions in the system before it can be resolved. Both of these
extensions are part of a standard MacOS install. If you are experiencing
such problems using the AutoShare Admin, it is more than likely they have
been turned off via the Extensions Manager."
> Is version 2.4 of AutoShare stable? I'd try it if I have no luck with 3.
It has become somewhat boring (in a pleasant way though!), but I haven't
for a couple of years come across an AutoShare server application
originated crash or freeze being reported and confirmed. The general
recommendation is to run DFA/Norton, check your Mac OS, use a fresh
AutoShare environment, narrow it the best you possibly can and then mail me
with the details needed to narrow down the problem, so I can reproduce and
subsequently fix it. There is furthermore always the chance of a compiler
related bug, in which case I would aim to work around it.
Date: Thu, 26 Nov 1998 12:58:51 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Listmembers, archives and advice
At 19:25 +0000 11/26/98, Bill Bedford wrote:
> I have had a couple calls for help from listmembers about problem they are
> having with downloading files from the archive folder.
>
> The first person cannot down load any file, because of a MIME problem. This
> is part of the header from the SIMS copy of the incoming file.
>
>> To: autoshare at mousa.demon.co dot uk
>> Subject: GET scalefour_list SUPPLIER.TEXT
>> MIME-version: 1.0
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-transfer-encoding: quoted-printable
>> X-Mailer: TFS Gateway /310000000/310101449/310101419/310200725/
>> X-Engine: "TFS Engine Release 3.12 Build 101"
>>
>> GET scalefour_list SUPPLIER.TEXT
>>
>
> note the dot in the file name has been encoded -- autoshare returns it as
> file unknown.
The dot in SUPPLIER.TEXT has been encoded? I don't understand.
> The second person as successfully download a file which has been zipped and
> binhexed and wants to how to read it using only Microsoft tools............
Doesn't StuffIt Expander come with any Microsoft software?
Subject: Re: Stuffit Expander
Date: Thu, 26 Nov 98 16:03:40 -0600
From: Jon & Janelle Gardner <jgardner at kairosnet dot com>
>> The second person as successfully download a file which has been zipped and
>> binhexed and wants to how to read it using only Microsoft tools............
>
>Doesn't StuffIt Expander come with any Microsoft software?
Tell 'em to download Stuffit Expander for Windows:
<ftp://ftp.scruz.net/users/aladdin/public/pc/Expander_for_Windows/Aladdin_E
xpander_2_Install.EXE>
Jon
<><
Jon & Janelle Gardner <mailto:jgardner at kairosnet dot com> <AOLIM:DaGardners>
Kairos Network Services <http://www.kairosnet.com/kairos/>
PGP public key available at <http://www.kairosnet.com/kairos/pgpkey.html>
...as for me and my household, we will serve the Lord. (Joshua 24:15 NIV)
Date: Fri, 27 Nov 1998 14:55:08 +0200
From: Robert Brenstein <rjb at rz.uni-potsdam dot de>
Subject: Re: Re: AutoShare Admin
>> I am a brand new user of AutoShare 3.0.2. I haven't actually succeeded to
>> get it going, yet. I followed the quick start guide. I managed to subscribe
>> correctly, but when I sent a post, my server crashed (turned itself off).
>> When I restarted it and watched, it sat forever processing the incoming
>> mail until it crashed again. The lookup into various files revealed that
>> one contains an ever repeating mail header after the actual file. Sth loops
>> for some reason.
>
> Could you send that file (StuffIt'ed!) to me (meh at dnai dot com)? Thanks.
Sorry, I deleted it.
> You probably have a corrupt preferences file or a corrupt or malformed
> message file.
There was a mail file in the Eudora's Incoming Mail folder that was empty
and was generating an infitely-repeating error about a file being sent from
postmaster back to the list with error code in the log indicating that file
is missing. I suspect, however, that it was a result of the crash not the
reason (Eudora was not crashing after restart, just generating errors for
ever). I believe that the postmaster mail file was generated as a result of
bogus subscriber addresses (userid1@domain1) in the sample files. There
was no mention (or I missed it) in the quick start about editing these and
I spotted them only when trying to figure out what went wrong. I will
check prefs, but it is a text file that I opened with bbedit with no
problems.
>> Is there a reason why FaceSpan extension would not work on a WS8150
>> w/MacOS 7.1?
>
> The following quotes from the documentation may be of some help.
>
> Getting started
> Installing AutoShare
> System requirements
>
> "AutoShare runs on any Macintosh model, but does require System 7.5 or
> later (for the scriptable Finder)."
Why would your program need scriptable Finder? Would the extension that
makes Finder in OS 7.1 scriptable be sufficient? I am doing quite a bit of
AppleScripting and I found that using Finder usually slows things down.
Can't you use OSAX to make it not relying on Scriptable Finder and thus
compatible with 7.1 for those of us behind the times?
All my server software is kinda old, hence so far I hesitated upgrading.
The server worked with no single crash (until now) since Aug 97. And it
runs AS, WWW, FTP, POP/SMTP, Time, etc. I may have to move to 7.6.1,
though, if that is required. However, your server program seems to work
under 7.1 handling at least the autoreply and subscription without problem.
> Running the server
> Interfaces
> AutoShare Admin application
>
> "The FaceSpan Extension is expecting to find the QuickTime and QuickTime
> PowerPlug extensions in the system before it can be resolved. Both of these
> extensions are part of a standard MacOS install. If you are experiencing
> such problems using the AutoShare Admin, it is more than likely they have
> been turned off via the Extensions Manager."
I have QT installed, although it is an older version (1.6 -- it came with
7.1). The docs do not indicate that a specific version is needed.
>> Is version 2.4 of AutoShare stable? I'd try it if I have no luck with 3.
>
> It has become somewhat boring (in a pleasant way though!), but I haven't
> for a couple of years come across an AutoShare server application
> originated crash or freeze being reported and confirmed. The general
> recommendation is to run DFA/Norton, check your Mac OS, use a fresh
> AutoShare environment, narrow it the best you possibly can and then mail me
> with the details needed to narrow down the problem, so I can reproduce and
> subsequently fix it. There is furthermore always the chance of a compiler
> related bug, in which case I would aim to work around it.
>
My server is sqeeky clean according to Norton and Disk First Aid. As I
said, my server has been very stable and AutoShare is the only new
addition. However, the crash could have been just a freak accident. Since
upgrading OS on my server is not an option at the moment, I'll try using an
older AutoShare.
Robert
Date: Fri, 27 Nov 1998 17:43:40 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Re: AutoShare Admin
At 14:55 +0200 11/27/98, Robert Brenstein wrote:
> Why would your program need scriptable Finder?
It's not because of FaceSpan 2.1, which merely requires AppleScript 1.1,
which was released before Mac OS 7.5, which introduced the scriptable
Finder.
I spent some idle time looking through the Admin script code with a fine
toothcomb. It turned out that 9 of 14 Finder tell wrappers weren't actually
needed as the commands in those compound statements are stored in standard
Mac OS scripting additions and not within the Finder dictionary. That's how
it goes when you don't take the time to check when writing the code.
> Would the extension that makes Finder in OS 7.1 scriptable be sufficient?
I have forgotten all about that. Do you have a good URL detailing it?
> I am doing quite a bit of AppleScripting and I found that using Finder
> usually slows things down.
Yeah, I have heard that compound statements wrapped inside a Finder tell
are three times as slow.
> Can't you use OSAX to make it not relying on Scriptable Finder and thus
> compatible with 7.1 for those of us behind the times?
For those remaining 5 of 14 Finder tell wrappers, I may at some point
simply added one or several commands to the AutoShare dictionary. It's
stuff like "name of every item of container".
These 5 instances are all within the List names, Filters and Documents
windows, so you should be able to get by. I have uploaded a new version of
the Admin to the ftp site in the beta directory, but don't use it with a
server version earlier than 3.0.2.
> My server is sqeeky clean according to Norton and Disk First Aid. As I
> said, my server has been very stable and AutoShare is the only new
> addition. However, the crash could have been just a freak accident.
> Since upgrading OS on my server is not an option at the moment, I'll try
> using an older AutoShare.
It mostly likely was just a corrupt glitch, which can happen to the best of
resource forks. If it happens again, be sure to send me the files, so I can
look into it :-)
Date: Sat, 28 Nov 1998 12:54:50 +0000
From: Michael Hambly <michael at mayo-ireland dot ie>
Subject: Nearly there
Well as was suggested I had another go and stuck at it and I nearly have a
list ready for a newsletter. Just a couple of points:
First a suggestion for the documentation and please don't take offence
Mikael (who can complain about such a piece of software especially when it
is free).
I couldn't figure out how to supress the list and RFC fields from the
documentation section titled 'List and X-RFC fields' so I had to go into
RESedit. After that I went back to Autoshare Admin and discovered that the
codes were put into the Suppress RFC headers field. ( I had seen this but
didn't know what to type in) I'd suggest something like the following:
All of the above fields may optionally and individually be
turned on and off on a per-list basis (with the exception of
the List-Software field), see the list-specific configuration
for AppleScript or the Admin.
For example entering 13 into the 'List and X-RFC fields'
box would suppress List-Subscribe and X-List-Digest.
Now a question
I am trying to cut down the header even more. Can I suppress X-sender and
Precedence Bulk (I'm using the list in announcement mode). Also is it
possible to put the receipients e-mail address in the 'To' field rather
than the list address.
Thanks
Michael Hambly
* * * * * *
http://www.mayo-ireland.ie/ for sites on Ireland.
Researching your roots? http://mail.mayo-ireland.ie/webx?
Looking for a chat? http://chat.in-ireland.net/
Michael Hambly, Mayo Ireland Ltd, Claremorris, Co Mayo, Ireland
Tel: + 353 (0) 94 60209 Fax: + 353 (0) 94 60273
E-mail: michael at mayo-ireland dot ie
* * * * * *
Date: Sat, 28 Nov 1998 08:18:21 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Nearly there
At 12:54 +0000 11/28/98, Michael Hambly wrote:
> I couldn't figure out how to supress the list and RFC fields from the
> documentation section titled 'List and X-RFC fields' so I had to go into
> RESedit. After that I went back to Autoshare Admin and discovered that the
> codes were put into the Suppress RFC headers field. ( I had seen this but
> didn't know what to type in)
Why is it that people tend to forget about the balloon help? :-)
Running the server
Interfaces
AutoShare Admin application
"Balloon help [...] has been added to all windows, so that you may
instantly read about the various fields of these windows."
An initial time-saver is to turn on the balloon help and tour the fields of
the windows in the Admin to get an overview of how the interface is put
together.
> I am trying to cut down the header even more. Can I suppress X-sender and
> Precedence Bulk (I'm using the list in announcement mode).
I have chosen not to support this, as both relate to security and as the
SMTP protocol isn't particularly safe to begin with.
> Also is it possible to put the receipients e-mail address in the 'To'
> field rather than the list address.
No, this is usually beyond the scope of even simple server-based mailing
lists. Are you sure the recipients would actually prefer this?
Date: Sat, 28 Nov 1998 17:57:07 +0100
From: Detlef Beyer <d.beyer at crash dot de>
Subject: Re: Nearly there
> Why is it that people tend to forget about the balloon help? :-)
because most other developers simply ignore the balloon help, so the user
get's used to ignoring the balloon help too...
>> I am trying to cut down the header even more. Can I suppress X-sender and
>> Precedence Bulk (I'm using the list in announcement mode).
>
> I have chosen not to support this, as both relate to security and as the
> SMTP protocol isn't particularly safe to begin with.
Precendence Bulk give some trouble with many of the big companies mail
servers - the sysops define "bulk" to be identical to "junk"... I build a
process extender to remove the precendence bulk header - if anybody needs
it... (I still think this should be an option of Autoshare - why don't you
let us be responsible for what we configure here?)
Happy weekend,
Detlef
Date: Sat, 28 Nov 1998 09:05:10 -0800
From: "Terry R. Schussler" <schussler at gmatter dot com>
Subject: Re: Nearly there
At 8:18 AM -0800 11/28/98, Mikael Hansen wrote:
> At 12:54 +0000 11/28/98, Michael Hambly wrote:
>
>> I couldn't figure out how to supress the list and RFC fields from the
>> documentation section titled 'List and X-RFC fields' so I had to go into
>> RESedit. After that I went back to Autoshare Admin and discovered that the
>> codes were put into the Suppress RFC headers field. ( I had seen this but
>> didn't know what to type in)
>
> Why is it that people tend to forget about the balloon help? :-)
>
I have to say that it is the Balloon Help that I really use to familiarize
myself with the functions of the software. An excellent implementation!
Regards,
Terry
....----===|| Terry R. Schussler ||===----....
....----===|| schussler at gmatter dot com ||===----....
SUBSCRIBE to the XTRAS-L discussion list (http://www.gmatter.com/xtras-l.html)
DOWNLOAD and SHARE behaviors at (http://www.behaviors.com/)
Date: Sun, 29 Nov 1998 02:23:24 +0000
From: Michael Hambly <michael at mayo-ireland dot ie>
Subject: Re: Nearly there
>At 12:54 +0000 11/28/98, Michael Hambly wrote:
>
>> I couldn't figure out how to supress the list and RFC fields from the
>> documentation section titled 'List and X-RFC fields' so I had to go into
>> RESedit. After that I went back to Autoshare Admin and discovered that the
>> codes were put into the Suppress RFC headers field. ( I had seen this but
>> didn't know what to type in)
>
>Why is it that people tend to forget about the balloon help? :-)
Probably because it is usually useless and a waste of time - I'll know
better for Autoshare :-)
Thanks
Michael
* * * * * *
http://www.mayo-ireland.ie/ for sites on Ireland.
Researching your roots? http://mail.mayo-ireland.ie/webx?
Looking for a chat? http://chat.in-ireland.net/
Michael Hambly, Mayo Ireland Ltd, Claremorris, Co Mayo, Ireland
Tel: + 353 (0) 94 60209 Fax: + 353 (0) 94 60273
E-mail: michael at mayo-ireland dot ie
* * * * * *
Date: Sun, 29 Nov 1998 02:27:02 +0000
From: Michael Hambly <michael at mayo-ireland dot ie>
Subject: Re: Bulk
>>> I am trying to cut down the header even more. Can I suppress X-sender and
>>> Precedence Bulk (I'm using the list in announcement mode).
>>
>> I have chosen not to support this, as both relate to security and as the
>> SMTP protocol isn't particularly safe to begin with.
>
>Precendence Bulk give some trouble with many of the big companies mail
>servers - the sysops define "bulk" to be identical to "junk"... I build a
>process extender to remove the precendence bulk header - if anybody needs
>it... (I still think this should be an option of Autoshare - why don't you
>let us be responsible for what we configure here?)
>
>Happy weekend,
>
>Detlef
Detlef
I'd like a copy please, the idea of rejection is what promoted my notion to
remove 'bulk' .
Thanks
Michael
* * * * * *
http://www.mayo-ireland.ie/ for sites on Ireland.
Researching your roots? http://mail.mayo-ireland.ie/webx?
Looking for a chat? http://chat.in-ireland.net/
Michael Hambly, Mayo Ireland Ltd, Claremorris, Co Mayo, Ireland
Tel: + 353 (0) 94 60209 Fax: + 353 (0) 94 60273
E-mail: michael at mayo-ireland dot ie
* * * * * *
Date: Sun, 29 Nov 1998 03:12:22 +0000
Subject: Re: Nearly there
From: "James Berriman" <J.R.Berriman at staffs.ac dot uk>
Detlef wrote:
>Precendence Bulk give some trouble with many of the big companies mail
>servers - the sysops define "bulk" to be identical to "junk"...
I wonder what they do with Precedence: List? Do they just trash everything
with a precedence header?
( :-]) James
Date: Sun, 29 Nov 1998 20:31:30 -0500
Subject: Re: Moderated list quirk
From: "Shan Vosseller" <updates at vsarts dot org>
No, redirect with Outlook Express (please don't get on a "switch
applications" rant here). I think that the behavior of redirect SHOULD act
as OE does since the idea is to take the message, fully intact and
untouched, and redirect it (instead of forward it).
-Shan
Date: Sun, 29 Nov 1998 19:11:16 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Nearly there
At 17:57 +0100 11/28/98, Detlef Beyer wrote:
> I build a process extender to remove the precendence bulk header - if
> anybody needs it... (I still think this should be an option of Autoshare
> - why don't you let us be responsible for what we configure here?)
The question kind of has a contradictory ring to it, as "configure" implies
less responsibility for the administrator than "build" does. Anyone can
occasionally forget about a checkbox click, but writing a process extender
makes you think twice about the risk of a mail loop.
At 03:12 +0000 11/29/98, James Berriman wrote:
> Detlef wrote:
>
>>Precendence Bulk give some trouble with many of the big companies mail
>>servers - the sysops define "bulk" to be identical to "junk"...
>
> I wonder what they do with Precedence: List? Do they just trash everything
> with a precedence header?
I don't know, and AutoShare doesn't distinguish among the three (a filter
process extender can however). But it's interesting how quiet the RFC's are
about this entire topic.
Date: Sun, 29 Nov 1998 19:14:04 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Moderated list quirk
At 20:31 -0500 11/29/98, Shan Vosseller wrote:
> No, redirect with Outlook Express (please don't get on a "switch
> applications" rant here). I think that the behavior of redirect SHOULD act
> as OE does since the idea is to take the message, fully intact and
> untouched, and redirect it (instead of forward it).
OE, at least the Mac 4.01 version, doesn't actually do that: the SMTP
envelope sender is not the original sender, but updated to the redirecting
sender; the Return-Path field and Received field(s) are also likely to be
different.
Eudora distinguishes redirecting from forwarding in several ways: 1. the
redirect adds "by way of (<...>)", while forward updates to the redirecting
sender, and 2. the message body is not quoted.
In any event, it would seem that the more you stress that the message body
is one thing and the rest (the RFC header and the SMTP envelope) is
something else, the more do you stress the responsibility of the
redirecting sender.
As this is somewhat related to another response that I have posted a few
minutes ago, it may be noted that a process extender can be designed to
remove the Precedence header. It _can_ be done.
Date: Mon, 30 Nov 1998 10:25:00 +0200
From: Robert Brenstein <rjb at rz.uni-potsdam dot de>
Subject: Re: Re: Re: AutoShare Admin
On Fri, 27 Nov 1998 17:43:40 -0800, Mikael Hansen <meh at dnai dot com> wrote:
> At 14:55 +0200 11/27/98, Robert Brenstein wrote:
>
>> Why would your program need scriptable Finder?
>
> It's not because of FaceSpan 2.1, which merely requires AppleScript 1.1,
> which was released before Mac OS 7.5, which introduced the scriptable
> Finder.
>
> I spent some idle time looking through the Admin script code with a fine
> toothcomb. It turned out that 9 of 14 Finder tell wrappers weren't actually
> needed as the commands in those compound statements are stored in standard
> Mac OS scripting additions and not within the Finder dictionary. That's how
> it goes when you don't take the time to check when writing the code.
Are you saying that the server itself should work under 7.1 and it is just
the Admin that needs scriptable Finder? That I can live with.
>> Would the extension that makes Finder in OS 7.1 scriptable be sufficient?
>
> I have forgotten all about that. Do you have a good URL detailing it?
Not off hand. I think I got it with an AppleScript book.
Robert
Date: Mon, 30 Nov 1998 12:05:38 +0200
From: Robert Brenstein <rjb at rz.uni-potsdam dot de>
Subject: Re: Re: Re: AutoShare Admin
>> Can't you use OSAX to make it not relying on Scriptable Finder and thus
>> compatible with 7.1 for those of us behind the times?
>
> For those remaining 5 of 14 Finder tell wrappers, I may at some point
> simply added one or several commands to the AutoShare dictionary. It's
> stuff like "name of every item of container".
>
> These 5 instances are all within the List names, Filters and Documents
> windows, so you should be able to get by. I have uploaded a new version of
> the Admin to the ftp site in the beta directory, but don't use it with a
> server version earlier than 3.0.2.
>
I wonder if you could not use some other OSAXen to eliminate use of Finder
altogether. Check out Jon's Commands, GTQ Scripting Library, or Akua
Sweets, for example. They are all free. It would of course be nicer to not
rely on 3rd party OSAXen, but...
Robert
Subject: Re: AutoShare-Talk partial digest 30 Nov 1998
Date: Mon, 30 Nov 1998 10:01:58 -0500
From: Chuck <n1msa at maine.rr dot com>
I need some help getting the moderated part of autoshare working. I have
a list running and its working fine, but I cant seem to get itto be
moderated. Can anyone help me?. I am sure that I am missing a command or
something...If you can help please email me
n1msa at maine.rr dot com
Date: Mon, 30 Nov 1998 07:15:52 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Re: Re: AutoShare Admin
At 10:25 +0200 11/30/98, Robert Brenstein wrote:
> Are you saying that the server itself should work under 7.1 and it is
> just the Admin that needs scriptable Finder? That I can live with.
Yes, that's basically what I said (drop me a mail if it turns out that I'm
wrong). The Admin needs the scriptable Finder in a few relatively
insignificant places only.
I was almost going to say that the server application doesn't need the
scriptable Finder, but it does call the Finder in order to restart or shut
down the Mac when the system command in remote administration by e-mail is
used. You can simply choose not to use that feature though.
Date: Mon, 30 Nov 1998 12:19:06 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: Moderated list
At 10:01 -0500 11/30/98, Chuck wrote:
> I need some help getting the moderated part of autoshare working. I have
> a list running and its working fine, but I cant seem to get itto be
> moderated.
Have you clicked on the Moderated radio button in the Admin's List window?
What are you experiencing more specifically?
Date: Mon, 30 Nov 1998 13:56:22 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: RE: Big Files are killing Autoshare
At 11:58 AM -0500 on 11/24/98, Suarez, William wrote:
> Interesting, I've had no failures at all since I bumped up the memory
> partition and I've sent through some "nasty" attachments.
>
> Is it the same attachment each time that kills it or will any large
> attachment do it?
I've experimented, and it is any large attachment (experiment sizes ranged
from 2.1 meg to 4.0 meg).
Bill
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Mon, 30 Nov 1998 14:01:00 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Re: Big Files are killing Autoshare
At 11:30 PM -0500 on 11/25/98, Jerry Thompson wrote:
> >At 1:22 AM -0800 on 11/24/98, Mikael Hansen wrote:
>
> >> Are you sure? I have never come across that. But it's slow alright with
> >> those mega attachments. Try adding the letter K to the List Stuff field,
> >> which removes the attachment at an early stage. Still slow, but faster
> >> though.
> >>
> >
> >As a test, I just tried it again. I sent a file which resulted in a 2.9
> >Meg attachment to a list which is set to reject large files. The file made
> >it through EIMS, and got into the Filed Mail folder in Autoshare. The
> >Autoshare window said it was processing it, and after processing for a
> >couple of minutes, the Autoshare application crashed error 10. Sometimes
> >it gives the error message, sometimes it just crashes with no error
> >message, but it _always_ crashes when a file of this size gets received.
>
>
> Wouldn't it be simpler to just change the largest email size for the list's
> EIMS account to prevent this from happening?
>
No, because normal e-mail to the admin account is okay for large
attachments. It's only to the mailing lists that it hurts, and it sounds
like Mikael has made an enhancement to resolve this issue. I'll be taking
a look soon...
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Mon, 30 Nov 1998 14:33:31 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Re: Big Files are killing Autoshare STILL
At 6:48 AM -0800 on 11/25/98, Mikael Hansen wrote:
>
> The server can do a lot better, so I decided to go for a qualified guess at
> where the ending MIME boundary is at (detaching is a somewhat not entirely
> safe task anyway), which brought it down to 22 seconds. This is most likely
> what you would be looking at when using the 3.0.3b3.
>
> The fun really kicks in when you aim to reattach using the letter O in the
> List Stuff field (and when it works). 39 seconds (down from 19:58).
>
Okay, do I need to do to get the results you are getting? I have a "k" in
the list stuff field, but I'm still having the same problem as before.
Scenario:
I have a 2.9 meg attachment in the Filed Mail folder (b2801c15). When I
startup Autoshare 3.0.3b3, autoshare creates a new file (b2801c15.$). Then
I watch as the size of the file climbs and climbs as it approaches the 2.9
meg size. The only difference I see now is that the Autoshare window does
not display the "Processing: b2801c15" message it used to display. Now
it's just blank as if it was not processing anything, but it's definitely
doing something, as that file is growing and growing. Autoshare dies
before it ever completes (or maybe it's right when it does complete... I'm
not sure).
Help!
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Mon, 30 Nov 1998 14:35:14 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Re: Big Files are killing Autoshare
To add to my last note, I've also noticed that Autoshare refuses to quit
while it's processing the file. The Quit is enabled under the File menu,
but when I select it, Autoshare does not quit. <sigh>
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Mon, 30 Nov 1998 14:42:03 -0700
From: Camelot Administrator <camelot.admin at lmco dot com>
Subject: Upon closer observation, it's actually worse now
Since I was unable to Quit from the last test on large attachments sent to
my mailing list, I sat and watched it again, and this time I saw how far it
got.
What's new in 3.0.3b3 is this process of creating the xxxxx.$ file.
Before, Autoshare immediately began processing the 2.9 meg file, and died
after 4 minutes. Now, it creates this xxxxx.$ file, and the file grows
slowly until it matches the size of the attachment. When it reaches the
size, the xxxxx.$ file disappears, and then Autoshare's window shows the
"Processing" message, and after 4 minutes of processing, it dies.
I hope this added bit of information helps you pinpoint the problem. If it
helps, I can send you the file in the Filed Mail folder.
Bill
+----------------------------------------------------------------+
| Camelot Postmaster, mailto:camelot.admin at lmco dot com |
| Lockheed Martin, Enterprise Information Systems, Sunnyvale, CA |
+----------------------------------------------------------------+
Date: Tue, 01 Dec 1998 02:12:03 +0000
Subject: Re: Moderated list
From: "James Berriman" <james at dcl.co dot uk>
Chuck, you accidentally quoted the whole digest.
( :-]) James
>From: Chuck <n1msa at maine.rr dot com>
>To: AutoShare-Talk at frutiger.staffs.ac dot uk (Subscribers of AutoShare-Talk)
>Subject: Re: AutoShare-Talk digest 30 Nov 1998
>Date: Mon, Nov 30, 1998, 22:41
>
>
>************************************************************
>Message body too big (237 > 150), forwarded to the moderator
>************************************************************
[snip]
>
>>Date: Mon, 30 Nov 1998 12:19:06 -0800
>>From: Mikael Hansen <meh at dnai dot com>
>>Reply-To: AutoShare-Talk at frutiger.staffs.ac dot uk (Subscribers of
>>AutoShare-Talk)
>>Subject: Re: Moderated list
>>
>>At 10:01 -0500 11/30/98, Chuck wrote:
>>
>>> I need some help getting the moderated part of autoshare working. I have
>>> a list running and its working fine, but I cant seem to get itto be
>>> moderated.
>>
>>Have you clicked on the Moderated radio button in the Admin's List window?
>>What are you experiencing more specifically?
>
>I got that part. Its the forwarding them or whatever with a pw to allow
>them to post im lost at and cant find documentation on it...