Menu
▾
▴
fetchmail-users
|
From: Kyle Contreras-B. <kyl...@gm...> - 2007-05-12 03:45:12
|
Hello, folks; I've been beginning to try and run fetchmail (through Cygwin, on a Windows box) to backup my Gmail account, for which I've been using the following in .fetchmailrc: poll pop.gmail.com with proto POP3 service 995 and options no dns user so...@gm... there with password PASSWORD is me here options ssl The first few times I queried pop.gmail.com, all went well. However, it's now been reporting the following (I've snipped out the pieces that seemed normal and the long list of messages): fetchmail: removing stale lockfile <snip> fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate verification error: unable to verify the first certificate <snip> reading message so...@gm...@pop.gmail.com:x of x (14003782 octets) Trying to connect to 127.0.0.1/25...connection failed. fetchmail: connection to localhost:smtp [127.0.0.1/25] failed: Connection refused. fetchmail: SMTP connect to localhost failed fetchmail: can't raise the listener; falling back to /usr/bin/procmail -d %T# Then, after going through a long series of asterisks and periods, fetchmail reports a socket error and ends with 'status=2'. Does anybody know what I might be doing wrong here? Any help would be greatly appreciated, and apologies all around if I'm just being very silly or should be asking on a Cygwin list. Thanks, Kyle |
|
From: Matthias A. <mat...@gm...> - 2007-05-12 14:59:43
|
On Fri, 11 May 2007, Kyle Contreras-Barbour wrote: > Then, after going through a long series of asterisks and periods, fetchmail > reports a socket error and ends with 'status=2'. > > Does anybody know what I might be doing wrong here? Any help would be > greatly appreciated, and apologies all around if I'm just being very silly > or should be asking on a Cygwin list. First of all, is your fetchmail current? Should be 6.3.8, but 6.3.6 should also work somewhat. Next, do you have procmail installed? Both can be fixed with the Cygwin setup.exe. Third, if you originally injected into Exim or some such, be sure to start that daemon at boot time (requires some NT-ish operating system AFAICS, NT, Win2K, XP or Vi$ta, details are in Jason Tishler's cygwin-readme file that should be on your system). -- Matthias Andree |
|
From: Kyle Contreras-B. <kyl...@gm...> - 2007-05-12 23:32:43
|
On 5/12/07, Matthias Andree <mat...@gm...> wrote: > > First of all, is your fetchmail current? Should be 6.3.8, but 6.3.6 > should also work somewhat. > > Next, do you have procmail installed? > > Both can be fixed with the Cygwin setup.exe. > > Third, if you originally injected into Exim or some such, be sure to > start that daemon at boot time (requires some NT-ish operating system > AFAICS, NT, Win2K, XP or Vi$ta, details are in Jason Tishler's > cygwin-readme file that should be on your system). Thanks for the reply! Fetchmail appears to be current, and procmail is installed (they're versions 6.3.8 and 3.22, respectively, according to setup.exe). I did indeed need to get exim running, it seems (thanks!) - I ran exim-config to get the daemon going and when I ran fetchmail, instead of giving "connection to localhost failed" it happily connected. However, it's still having certificate verification errors (I don't know if that's a big issue or not) and terminating with a socket error. This is what it's showing at the end: fetchmail: socket error while fetching from so...@gm...@pop.gmail.com fetchmail: 6.3.8 querying pop.gmail.com (protocol POP3) at <date>: poll completed fetchmail: Query status=2 (SOCKET) fetchmail: normal termination, status 2 It's been getting stuck at the same message, which appears to be fairly large (14003782 octets), so I'm starting to wonder if there isn't some issue there. Before it hits that message, it's giving this: 649 messages (292 seen) for so...@gm... at pop.gmail.com (21915850 octets). skipping message so...@gm...@pop.gmail.com:1 not flushed skipping message so...@gm...@pop.gmail.com:2 not flushed ... skipping message so...@gm...@pop.gmail.com:291 not flushed skipping message so...@gm...@pop.gmail.com:292 not flushed fetchmail: POP3> LIST 293 fetchmail: POP3< +OK 293 14003782 fetchmail: POP3> RETR 293 fetchmail: POP3< +OK message follows reading message so...@gm...@pop.gmail.com:293 of 649 (14003782 octets) Trying to connect to 127.0.0.1/25...connected. fetchmail: SMTP< 220 <hostname> ESMTP Exim 4.66 Sat, 12 May 2007 14:04:08 -0700 fetchmail: SMTP> EHLO <hostname> fetchmail: SMTP< 250-<hostname> Hello localhost [127.0.0.1] fetchmail: SMTP< 250-SIZE 52428800 fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250 HELP fetchmail: SMTP> MAIL FROM:<so...@gm...> SIZE=14003782 fetchmail: SMTP< 250 OK fetchmail: SMTP> RCPT TO:<username@hostname> fetchmail: SMTP< 250 Accepted fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself #<massive string of asterisks, interrupted by periods> Any further thoughts? Thanks again so much. Kyle |
|
From: Rob M. <rob...@gm...> - 2007-05-13 00:06:06
|
On 5/12/07, Kyle Contreras-Barbour <kyl...@gm...> wrote: > 6.3.8 and 3.22, respectively, according to setup.exe). > > I did indeed need to get exim running, it seems (thanks!) - I ran > exim-config to get the daemon going and when I ran fetchmail, instead of > giving "connection to localhost failed" it happily connected. However, it's > still having certificate verification errors (I don't know if that's a big > issue or not) and terminating with a socket error. This is what it's showing > at the end: Not a big deal. > It's been getting stuck at the same message, which appears to be fairly > large (14003782 octets), so I'm starting to wonder if there isn't some issue > there. Before it hits that message, it's giving this: > > 649 messages (292 seen) for so...@gm... at pop.gmail.com (21915850 > octets). > skipping message so...@gm...@pop.gmail.com:1 not flushed > skipping message so...@gm...@pop.gmail.com:2 not flushed > ... > skipping message so...@gm...@pop.gmail.com:291 not flushed > skipping message so...@gm...@pop.gmail.com:292 not flushed > fetchmail: POP3> LIST 293 > fetchmail: POP3< +OK 293 14003782 > fetchmail: POP3> RETR 293 > fetchmail: POP3< +OK message follows > reading message so...@gm...@pop.gmail.com:293 of 649 (14003782 octets) > > Trying to connect to 127.0.0.1/25...connected. > fetchmail: SMTP< 220 <hostname> ESMTP Exim 4.66 Sat, 12 May 2007 14:04:08 > -0700 > fetchmail: SMTP> EHLO <hostname> > fetchmail: SMTP< 250-<hostname> Hello localhost [127.0.0.1] > fetchmail: SMTP< 250-SIZE 52428800 > fetchmail: SMTP< 250-PIPELINING > fetchmail: SMTP< 250 HELP > fetchmail: SMTP> MAIL FROM:<so...@gm...> SIZE=14003782 > fetchmail: SMTP< 250 OK > fetchmail: SMTP> RCPT TO:<username@hostname> > fetchmail: SMTP< 250 Accepted > fetchmail: SMTP> DATA > fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself > #<massive string of asterisks, interrupted by periods> <--- following section moved into what appears to be the right place ---> > fetchmail: socket error while fetching from so...@gm...@pop.gmail.com > fetchmail: 6.3.8 querying pop.gmail.com (protocol POP3) at <date>: poll > completed > fetchmail: Query status=2 (SOCKET) > fetchmail: normal termination, status 2 It could be a problem related to your exim config (14 MB is pretty large for an email). The contents of the exim log would be useful to further diagnose, though from the snippet above it doesn't appear to be a fetchmail problem. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
|
From: Jason T. <ja...@ti...> - 2007-05-14 02:42:17
|
Kyle,
On Sat, May 12, 2007 at 11:03:18PM +0100, Rob MacGregor wrote:
> On 5/12/07, Kyle Contreras-Barbour <kyl...@gm...> wrote:
> > 6.3.8 and 3.22, respectively, according to setup.exe).
> >
> > I did indeed need to get exim running, it seems (thanks!) - I ran
> > exim-config to get the daemon going and when I ran fetchmail,
> > instead of giving "connection to localhost failed" it happily
> > connected. However, it's still having certificate verification
> > errors (I don't know if that's a big issue or not) and terminating
> > with a socket error. This is what it's showing at the end:
>
> Not a big deal.
Agreed, I get the same error messages when I fetch from gmail too.
> > It's been getting stuck at the same message, which appears to be
> > fairly large (14003782 octets), so I'm starting to wonder if there
> > isn't some issue there. Before it hits that message, it's giving
> > this:
> >
> > [snip]
>
> It could be a problem related to your exim config (14 MB is pretty
> large for an email). The contents of the exim log would be useful to
> further diagnose, though from the snippet above it doesn't appear to
> be a fetchmail problem.
You don't need to use exim or another MTA, if you are only interested in
local mail delivery. If so, then you may want to model your fetchmail
configuration after mine which delivers via procmail:
poll "pop.gmail.com"
protocol pop3
username "${USER}@gmail.com"
password "${PASSWORD}"
fetchall
ssl
nokeep
mda "/usr/bin/procmail -d %T"
where ${USER} and ${PASSWORD} are as appropriate.
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
|
|
From: Kyle Contreras-B. <kyl...@gm...> - 2007-05-14 09:04:07
|
On 5/13/07, Jason Tishler <ja...@ti...> wrote: > > You don't need to use exim or another MTA, if you are only interested in > local mail delivery. If so, then you may want to model your fetchmail > configuration after mine which delivers via procmail: > > <snip> > I've put that into my rc file now, but I'm still getting socket errors at the same point, at the 14MB e-mail. It could be a problem related to your exim config (14 MB is pretty > large for an email). The contents of the exim log would be useful to > further diagnose, though from the snippet above it doesn't appear to > be a fetchmail problem. > I'm happy to post it - it's rather large, so here's a snippet. Let me know if more (or a specific segment) would be helpful. 2007-05-13 20:59:25 Start queue run: pid=1596 2007-05-13 20:59:25 End queue run: pid=1596 2007-05-13 21:14:26 Start queue run: pid=1640 2007-05-13 21:14:26 End queue run: pid=1640 2007-05-13 21:29:26 Start queue run: pid=1660 2007-05-13 21:29:26 End queue run: pid=1660 2007-05-13 21:44:27 Start queue run: pid=1720 2007-05-13 21:44:27 End queue run: pid=1720 2007-05-13 21:59:28 Start queue run: pid=1064 2007-05-13 21:59:28 End queue run: pid=1064 2007-05-13 22:14:47 Start queue run: pid=1208 2007-05-13 22:14:48 End queue run: pid=1208 2007-05-13 22:30:06 Start queue run: pid=1660 2007-05-13 22:30:06 End queue run: pid=1660 2007-05-13 22:45:06 Start queue run: pid=1460 2007-05-13 22:45:06 End queue run: pid=1460 2007-05-13 23:00:06 Start queue run: pid=1208 2007-05-13 23:00:06 End queue run: pid=1208 2007-05-13 23:15:07 Start queue run: pid=1208 2007-05-13 23:15:07 End queue run: pid=1208 2007-05-13 23:30:07 Start queue run: pid=1440 2007-05-13 23:30:07 End queue run: pid=1440 2007-05-13 23:45:07 Start queue run: pid=868 2007-05-13 23:45:07 End queue run: pid=868 Farther back than this, there's some entries such as this one: 2007-05-12 14:35:22 SMTP connection from localhost (<hostname>) [127.0.0.1] lost while reading message data Again, thanks for all the help in figuring this out. Kyle |
|
From: Rob M. <rob...@gm...> - 2007-05-14 10:41:19
|
On 5/14/07, Kyle Contreras-Barbour <kyl...@gm...> wrote:
>
> I'm happy to post it - it's rather large, so here's a snippet. Let me know
> if more (or a specific segment) would be helpful.
>
> 2007-05-13 20:59:25 Start queue run: pid=1596
> 2007-05-13 20:59:25 End queue run: pid=1596
<---SNIP many near identical lines--->
If that truely is the related entries from your exim log then it would
suggest you've either got some very broken logging, or you're not
actually using exim. I'd expect to see some lines relating to the
receipt of the problem email.
> Farther back than this, there's some entries such as this one:
>
> 2007-05-12 14:35:22 SMTP connection from localhost (<hostname>) [127.0.0.1]
> lost while reading message data
What else is there around this? Your careful snipping of the logs
makes it impossible to help you - we need context!
What I/we need to see is the output of "fetchmail --nosyslog
--nodetach -vvv" for the problem email AND the entries from your exim
log (assuming you're delivering via exim) for that point in time. We
also really need to see the contents of your .fetchmailrc (passwords
obscured).
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Kyle Contreras-B. <kyl...@gm...> - 2007-05-14 15:22:31
|
On 5/14/07, Rob MacGregor <rob...@gm... > wrote: > > > Farther back than this, there's some entries such as this one: > > > > 2007-05-12 14:35:22 SMTP connection from localhost (<hostname>) [127.0.0.1 > ] > > lost while reading message data > > What else is there around this? Your careful snipping of the logs > makes it impossible to help you - we need context! Sorry... I'm not meaning to be difficult. There isn't anything around that other than nearly identical "start queue run" and "end queue run" lines. Based on your comments here and the addition of 'mda "/usr/bin/procmail -d %T"' to my .fetchmailrc I'm guessing that I'm not actually using exim. What I/we need to see is the output of "fetchmail --nosyslog > --nodetach -vvv" for the problem email AND the entries from your exim > log (assuming you're delivering via exim) for that point in time. We > also really need to see the contents of your .fetchmailrc (passwords > obscured). O.K. Here's my current .fetchmailrc: poll "pop.gmail.com" protocol pop3 service 995 username "kyl...@gm..." password "<password>" ssl keep mda "/usr/bin/procmail -d %T" And here's the output of "fetchmail --nosyslog --nodetach -vvv": $ fetchmail --nosyslog --nodetach -vvv fetchmail: 6.3.8 querying pop.gmail.com (protocol POP3) at Mon May 14 05:53:57 2007: poll started Trying to connect to 64.233.167.111/995...connected. fetchmail: Issuer Organization: Equifax fetchmail: Unknown Issuer CommonName fetchmail: Server CommonName: pop.gmail.com fetchmail: pop.gmail.com key fingerprint: 59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: POP3< +OK Gpop ready for requests from 66.81.40.23f79pf3475397pyh fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< USER fetchmail: POP3< RESP-CODES fetchmail: POP3< EXPIRE 0 fetchmail: POP3< LOGIN-DELAY 300 fetchmail: POP3< X-GOOGLE-VERHOEVEN fetchmail: POP3< UIDL fetchmail: POP3< . fetchmail: POP3> USER kyl...@gm... fetchmail: POP3< +OK send PASS fetchmail: POP3> PASS * fetchmail: POP3< +OK Welcome. fetchmail: selecting or re-polling default folder fetchmail: POP3> STAT fetchmail: POP3< +OK 649 21915850 fetchmail: POP3> LAST fetchmail: POP3< -ERR Not supported fetchmail: Not supported fetchmail: POP3> UIDL fetchmail: POP3< +OK fetchmail: POP3< 1 GmailId106fbe14f6cfa650 <snip lines nearly identical to the above, counting from 2 to 292> fetchmail: POP3< 293 GmailId10869d8a1ae0cca0 fetchmail: 293 is unseen fetchmail: POP3< 294 GmailId1086cfbf8ea6c5dc fetchmail: 294 is unseen <snip lines nearly identical to the two above, counting from 295 to 648> fetchmail: POP3< 649 GmailId109d6cd4d6ef150d fetchmail: 649 is unseen fetchmail: POP3< . 649 messages (292 seen) for kyl...@gm... at pop.gmail.com (21915850 octets). skipping message kyl...@gm...@gmail-pop.l.google.com:1 not flushed skipping message kyl...@gm...@gmail-pop.l.google.com:2 not flushed <snip> skipping message kyl...@gm...@gmail-pop.l.google.com:292 not flushed fetchmail: POP3> LIST 293 fetchmail: POP3< +OK 293 14003782 fetchmail: POP3> RETR 293 fetchmail: POP3< +OK message follows reading message kyl...@gm...@gmail-pop.l.google.com:293 of 649 (14003782 octets) About to rewrite From: Kyle Contreras-Barbour <kyl...@gm...> Rewritten version is From: Kyle Contreras-Barbour <kyl...@gm...> About to rewrite To: "Kyle (me)" <kyl...@gm...> Rewritten version is To: "Kyle (me)" <kyl...@gm...> fetchmail: about to deliver with: /usr/bin/procmail -d 'snoutwood' #<snip 250+ lines of asterisks> fetchmail: socket error while fetching from kyl...@gm...@ pop.gmail.com fetchmail: 6.3.8 querying pop.gmail.com (protocol POP3) at Mon May 14 06:07:08 2007: poll completed fetchmail: discarding new UID list fetchmail: Query status=2 (SOCKET) fetchmail: Writing fetchids file. fetchmail: normal termination, status 2 fetchmail: Writing fetchids file. Thanks, Kyle |
|
From: Rob M. <rob...@gm...> - 2007-05-14 15:41:29
|
On 5/14/07, Kyle Contreras-Barbour <kyl...@gm...> wrote: > > Sorry... I'm not meaning to be difficult. That's ok :) > There isn't anything around that > other than nearly identical "start queue run" and "end queue run" lines. > Based on your comments here and the addition of 'mda "/usr/bin/procmail -d > %T"' to my .fetchmailrc I'm guessing that I'm not actually using exim. I suspect you're right, which makes diagnosing this more difficult (I don't know if there is any way to get logging info out of procmail). > O.K. Here's my current .fetchmailrc: > > poll " pop.gmail.com" > protocol pop3 > service 995 > username "kyl...@gm..." > password "<password>" > ssl > keep > mda "/usr/bin/procmail -d %T" Looks ok, there's certainly nothing there that'll cause a problem. <---SNIP---> > fetchmail: POP3< +OK message follows > reading message kyl...@gm...@gmail-pop.l.google.com:293 of 649 > (14003782 octets) > About to rewrite From: Kyle Contreras-Barbour <kyl...@gm...> > Rewritten version is From: Kyle Contreras-Barbour < kyl...@gm...> > > About to rewrite To: "Kyle (me)" <kyl...@gm...> > Rewritten version is To: "Kyle (me)" < kyl...@gm...> > > fetchmail: about to deliver with: /usr/bin/procmail -d 'snoutwood' > #<snip 250+ lines of asterisks> > fetchmail: socket error while fetching from kyl...@gm... > @pop.gmail.com <---SNIP---> That suggests a problem with the communication with the remote host (ppp.gmail.com). However, it wouldn't hurt to check some of the basics: 1) Do you have at least 14 MB of free space in /var (and possibly /tmp)? 2) Can you view this email via GMail? Can another mail client (say, Thunderbird) view this email? If you can get exim working it wouldn't hurt to remove the MDA line and get some log info. I suspect it won't show anything useful though. If you want to avoid fetchmail trying to download this email you can use the "limit" directive to tell it to skip emails above a certain size. See "Resource Limit Control Options" in the man page for details. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
|
From: Jason T. <ja...@ti...> - 2007-05-14 15:56:12
|
On Mon, May 14, 2007 at 02:39:06PM +0100, Rob MacGregor wrote:
> On 5/14/07, Kyle Contreras-Barbour <kyl...@gm...> wrote:
> > There isn't anything around that other than nearly identical "start
> > queue run" and "end queue run" lines. Based on your comments here
> > and the addition of 'mda "/usr/bin/procmail -d %T"' to my
> > .fetchmailrc I'm guessing that I'm not actually using exim.
>
> I suspect you're right, which makes diagnosing this more difficult (I
> don't know if there is any way to get logging info out of procmail).
You can enable verbose procmail logging by adding "VERBOSE=yes" to the
command line:
mda "/usr/bin/procmail VERBOSE=yes -d %T"
> [snip]
> > fetchmail: about to deliver with: /usr/bin/procmail -d 'snoutwood'
> > #<snip 250+ lines of asterisks>
> > fetchmail: socket error while fetching from kyl...@gm...
> > @pop.gmail.com
> <---SNIP--->
>
> That suggests a problem with the communication with the remote host
> (ppp.gmail.com).
Agreed. However, can you try this from a non-Cygwin host (e.g., Linux)
to rule out a Cygwin specific problem?
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
|
|
From: Kyle Contreras-B. <kyl...@gm...> - 2007-05-16 12:55:35
|
On 5/14/07, Rob MacGregor <rob...@gm... > wrote: > > That suggests a problem with the communication with the remote host > (ppp.gmail.com). However, it wouldn't hurt to check some of the > basics: > > 1) Do you have at least 14 MB of free space in /var (and possibly /tmp)? 2) Can you view this email via GMail? Can another mail client (say, > Thunderbird) view this email? > <snip> > > If you can get exim working it wouldn't hurt to remove the MDA line > and get some log info. I suspect it won't show anything useful > though. > > If you want to avoid fetchmail trying to download this email you can > use the "limit" directive to tell it to skip emails above a certain > size. See "Resource Limit Control Options" in the man page for > details. > <snip> > On 5/14/07, Jason Tishler < ja...@ti...> wrote: > You can enable verbose procmail logging by adding "VERBOSE=yes" to the > command line: > > mda "/usr/bin/procmail VERBOSE=yes -d %T" > <snip> > However, can you try this from a non-Cygwin host (e.g., Linux) > to rule out a Cygwin specific problem? > When running procmail with VERBOSE=yes, it outputs (snoutwood being my login): procmail: [588] Wed May 16 03:11:27 2007 procmail: Couldn't read "/home/snoutwood/-d" procmail: Locking "/var/spool/mail/snoutwood.lock" procmail: Assigning "LASTFOLDER=/var/spool/mail/snoutwood" procmail: Opening "/var/spool/mail/snoutwood" procmail: Acquiring kernel-lock procmail: [588] Wed May 16 03:11:28 2007 procmail: Unlocking "/var/spool/mail/snoutwood.lock" Subject: Camera manuals Folder: /var/spool/mail/snoutwood 1839916 When I removed the mda line and ran exim, /var/log/exim/exim_main.log looked like this: 2007-05-16 03:28:39 exim 4.66 daemon started: pid=852, -q15m, listening for SMTP on port 25 (IPv4) 2007-05-16 03:28:39 Start queue run: pid=1232 2007-05-16 03:28:39 End queue run: pid=1232 2007-05-16 03:40:03 SMTP connection from localhost (finnegan) [127.0.0.1] lost while reading message data I've got plenty of space (lots more than 14MB, anyway) in both /var and /tmp. I can view it in Gmail, and what of it I've downloaded is easily viewable in Thunderbird. It's got a few .pdf files attached to it (hence the size). I'll definitely use the size limit if I can't get it through somehow - seems like that's the best workaround if need be. It'd be nice to be able to grab the message with fetchmail, though. Sadly, I don't have access to a Linux box at the moment. Maybe soon - I'm currently having modem troubles, but hopefully they'll be fixed soon and I can give it a shot. If it is a problem with communication with ppp.gmail.com, is there much I can do about it? Also, it occurred to me that I'm using a dial-up connection: could that be affecting this at all (due to the length of download times, etc., maybe some sort of timeout issue)? Again, thanks for all the help! Kyle |
|
From: Rob M. <rob...@gm...> - 2007-05-16 13:35:28
|
On 5/16/07, Kyle Contreras-Barbour <kyl...@gm...> wrote: > > I've got plenty of space (lots more than 14MB, anyway) in both /var and > /tmp. I can view it in Gmail, and what of it I've downloaded is easily > viewable in Thunderbird. It's got a few .pdf files attached to it (hence the > size). <---SNIP---> > Sadly, I don't have access to a Linux box at the moment. Maybe soon - I'm > currently having modem troubles, but hopefully they'll be fixed soon and I > can give it a shot. If you're having comms problems then, given that downloading a 14 MB file over dialup will take some time, it may be related. One option you may want to look at is making use of the 30 trial period you can use VMWare for. That would allow you to stand up a virtual Linux box to test with, which would at least allow identification as to whether or not it's a Cygwin problem. > If it is a problem with communication with ppp.gmail.com, is there much I > can do about it? Also, it occurred to me that I'm using a dial-up > connection: could that be affecting this at all (due to the length of > download times, etc., maybe some sort of timeout issue)? Sadly there's nothing you can do about problems beyond the end of your network cable :) I'd, roughly, expect (if my maths is working) a 14 MB file to take about 40 minutes over a standard dialup (nominal 48 Kb/s, nothing else going on). If you're saying your connection is unstable then you've got a good window for problems to occur. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X