Works for me.

Any more information?

It works as long as a network connection exists...  I first noticed/experienced
this problem when I was completely disconnected...  just disconnected my eth0
(s-c 0.9.6-57) and I get one "connection failed" for each enabled account.  HTH.

Hmng? Should I interprete this as: 
 
"--offline does not work after the connection has gone down unexpectedly." 
 
? 
 
So claws thinks there is a connection and refuses --offline. If that's true we 
could just force close() on every existing socket, and wait until recv()s and 
send()s return with an socket exception. 
 
 

"--offline does not work after the connection has gone down unexpectedly." 

Not quite, though that is one interpretation...  in my case, I was out of town
and totally disconnected and powered off.... booted up my laptop (no network
connections) and issued "sylpheed &" as usual (wanting to read previously d/l'ed
mail), with the resultant delays.  Wanting to avoid this, I checked the man page
and noticed the --offline switch... "Great!" I thought...  issued the modified
command -- no change...  so the difference here is that there was no network at
any time prior to using the swtich...  HTH

You're making it pretty hard. :-) 
So did you start "sylpheed --offline" while having an existing sylpheed 
running? 

Sorry no...
s/delays.  Wanting/delays.  Stopped s-c.  Wanting/
s/avoid this/avoid checks & delays/
s/swtich/switch/
:^)

It still works for me.
Try the attached patch which adds some more debugging traces. Run sylpheed from
an xterm with "sylpheed --debug --offline" and when it has completely launched,
get the relevant log.

Created an attachment (id=103) [details]
More logs to watch for --offline

OK....  finally got some time to test this with patched 0.9.6-61...  my setup
has 3 of 6 accounts active; 2 are on my home server, and 1 in on the laptop
itself...  there are differences in processing depending on connection status...
 my tests were done with eth0 connected, then disconnected...

Both tests produced lots of identical output (obviously :) so I produced a diff
-u file from the logs...  In summary, with --offline, s-c connects to the remote
and local POP servers -- if there is no network connection, it doesn't check...
not even the local POP server which may be due to DNS failure from lack of
access to the remote POP/DNS server.

Created an attachment (id=105) [details]
diff -u of 2 log files

Pierre, thanks. I also need to have the output of main.c, can you grep the 
lines of both logs for "main.c"? I'm especially interested in those lines 
telling the off/online state. 

grep'ed for main.c in both files -- diff -u on this indicates both were
identical...

main.c:455:working off line
main.c:524:Processing (top level folder)...
main.c:532:done.
# repeat last 2 lines for each folder
main.c:346:working offline
main.c:353:should have set an online mode

HTH

Hi Alfons,

Well...  I was out of town last night and fired up the laptop with no network
connection whatsoever...  invoked s-c with --offline...  this time, I have 3
screen shots coming at you... one for each pop server that got checked...

From what I observed, it appears that --offline just changes work_offline to 1
when there is no network -- maybe just no DNS server; but I haven't tried to
look at the code, so this is pure speculation based on what you'll see in the
screen shots...

HTH

Created an attachment (id=107) [details]
screen shot -- server 1

Created an attachment (id=108) [details]
screen shot -- server 2

Created an attachment (id=109) [details]
screen shot -- server 3

The unbroken little bar in the lower right corner of the sylpheed window
shows that in each of these screenshots you are not in 'offline' mode.

|The unbroken little bar in the lower right corner 
|of the sylpheed window shows that in each of these 
|screenshots you are not in 'offline' mode.

Well, the explanation Pierre gave is still a bit dense,
but what I gather is that even with sylpheed --offline 
(with no previous sylpheed invoked - that right Pierre?),
sylpheed still checks the accounts.

Pierre, any idea whether you have some mail queued while
invoking sylpheed?

OK...  let's see if I can be any clearer ---  don't try to read anything else
into my comments (there are no between-the-lines implications -- just what
happened)  :^)

- no mail queued, just some unread mail
- shutdown laptop, disconnect network & USB devices
- travelled w/laptop powered off
- at destination, power up laptop (still configured for ethernet)
    - NO network connection of any sort
    - only cables: power & external mouse
- open terminal window
(at this point, .sylpheed/sylpheedrc contains work_offline=0 because that's the
normal state I run under; hence the reason the bar will be unbroken in the next
steps)
- issue "sylpheed --offline"
- s-c complains of DNS
- times out waiting for pop server 1
- I take screen shot, then click OK
[repeat previous 3 steps for next 2 pop servers]

Nothing else...  it's that simple to reproduce; actually... simpler...  no
travel required...  :^)

HTH :^)

I see (I think :) You use 'check for new mail at startup', and on start up
(sylpheed --offline) it first checks for new mail *before* going into offline
mode

|You use 'check for new mail at startup', and 
|on start up (sylpheed --offline) it first checks 
|for new mail *before* going into offline mode

Ah, that should be pretty easy to solve. :-)

> Ah, that should be pretty easy to solve. :-)

Cool!   Reversing the order, --offline should not check for mail even if a
network connection exists....  or, should there be --no<option> (i.e.,
--noreceive[-all] options too?  :^)

2003-11-21 [alfons]     0.9.6claws84

        * src/main.c
                no mail incorporation allowed with --offline param.
                fixes bug #374, "--offline ignored"