Ken Green, [KG] wrote:
KG> No. I had auto-connect for -managing folders and -when account is
KG> selected. NOT -by any command. Will try that and report back.
Ok.
KG> At what point does the folder's synchronization settings take over?
KG> If a folder is set to synch and it doesn't exist on the server,
KG> shouldn't it then get created?
Yes. This is the case.
KG> Or should it be created on the server first, or through Folder
KG> management, etc.?
I just created a new folder and set it to not sync.
I then opened 'Manage IMAP folders'. The test folder wasn't listed
there. I hit the 'reset' button to refresh the list. The test folder was
now listed. Interesting.
>> But then again, I only create folders at home and I do full sync's
>> with all folders at home. Maybe this is why corresponding server side
>> folders are being created. I'll do some testing later.
KG> Not sure what you mean by at home or why that would be different.
At home, my IMAP server is right beside me on the LAN. I don't have to
wait forever for things to happen. I can therefore test quickly. :)
The connection to my IMAP server from work is very slow. It takes a long
time to create folders and move messages. I don't filter messages at
work. It would take too long. All filtering is done from home with TB!
or on the server. I only read and reply to mail from work. I do only an
occasional message move or deletion.
KG> Actually, yes. I believe filtering to another folder WITHIN THAT
KG> ACCOUNT does in fact work. Will double-check, but I'm pretty sure that
KG> was one of my tests and it worked.
Ok, good. So the problem is with filtering from an IMAP folder to a
local common folder. This doesn't seem to be possible. I just tried it
and more than I expected happened.
I did the following:
- I created a common folder
- I then adjusted one of my read filters to filter to it.
- I then moved one of the target messages to my Inbox and marked it
unread.
- I opened the message where it was marked as read and moved to another
message. Not only was it not moved, but another message appeared with
no visible headers. Only the folder flag was visible. On looking at
the message source, there was a lot of gibberish. After that, the
Inbox was stuck. I had to restart SecureBat! to free things up. On the
next try at autofiltering to the common folder nothing happened. I
switched back the target folder to an IMAP folder and it worked again.
Strange bug.
KG> This explains why I cannot filter to common folders. By their very
KG> nature, common folders don't "belong" to any account. It appears that
KG> common folders and IMAP are not going to dance together. I can live
KG> with that.
Ok.
KG> You keep mentioning "manually filter" and it is confusing me. Aside
KG> from selecting the "Re-filter messages from a folder right-click" I
KG> don't know how you would *manually* filter.
Yes. That's the way to do it. However, that seems to be disabled in
TB! 2.03 beta/47. GONK!! :/
It seems to be OK here in SecureBat! Lite v2.03.47
KG> If you cannot filter across accounts, then filtering to common folders
KG> isn't going to happen. But if filtering across accounts will become
KG> available in the future, I don't see why filtering to common folders
KG> couldn't be implemented as well.
Agreed.
KG> The problem I see with filtering across accounts is the heavier
KG> traffic and server load. Is it substantially more complicated?
Other clients, namely Mulberry already have this ability. So I don't see
why this shouldn't be possible, especially if the accounts are on the
same IMAP server.
KG> The problem I may run into (and this may be because of the new "real"
KG> implementation of IMAP) is that for my business account, I have a filter
KG> that redirects messages to my cell phone, giving me a notification of
KG> when I get an e-mail. 99% of the time, the small amount of info sent is
KG> enough for me (my carrier truncates messages that are too long/too big).
Without autofiltering, this isn't possible, so a TB! IMAP account would
have you stuck.
KG> Also.. (get ready to roll your eyes...) I have been testing on my
KG> laptop, right? Well, guess what genius was testing on his laptop with
KG> accounts that were also being hit by the desktop running 1.62r... At
KG> the very least, this screwed up read flags. Who knows what other
KG> trouble this caused. I will remember to shut down the desktop while
KG> testing on the laptop.
Note that with two proper IMAP clients this shouldn't matter.
I have ThunderBird running now on this laptop. It's polling the same
IMAP account that SecureBat! is polling as we speak. No problems at all.
KG> Assuming that (like me) most of that mail would not contain
KG> attachments, running into server space problems won't be an issue.
KG> It would be nice to access all of the TBUDL list I have downloading
KG> since joining from wherever I am. Wouldn't the initial sync be a
KG> killer? Yikes!
Yes. It can be if it's a lot of messages and you're doing a full sync.
KG> Also, how does this affect searching?
At the moment TB! will only search the cache, i.e., what you have
downloaded.
KG> When you search on a IMAP folder, you're are searching the local
KG> copy, correct?
Yes.
KG> Is the search then the same speed/efficiency as searching a POP
KG> account folder with the same number of messages?
Yes.
KG> Mulberry is supposed THE premier GUI-based IMAP client. Personally, I
KG> liked the simplicity and "feel" of Becky. You are currently using only
KG> The Bat, though, right? Why/how did you come to that conclusion?
Mulberry is poorly multi-threaded. So if you're trying to do something
while Mulberry degotiates with the server during a sync operation,
forget it.
ThunderBird is very good but lacks those oh so important features, not
specifically IMAP related, that we've grown to so love and grown
accustomed to having in TB!. :) With server side filtering, TB! is
working pretty well for me.
KG> I was using the color groups as part of a test filter. I generally use
KG> color groups on messages that have already been filtered and are sitting
KG> in the correct box (ex: threads I want to watch, etc.) I can still do
KG> that, right?
Try read filters moving to another IMAP folder. You'll note that when
the message is moved to its new location, it loses the colour group
assignment you gave it.
KG> I just tested this... strange....
KG> Two messages that passed my previous test filter are colored red (they
KG> were supposed to be colored red and moved to a common folder, but the
KG> only changed color). I select one of those messages and move it to the
KG> common folder. Go to folder, message is there - STILL RED.
KG> Next, I try moving the other one to a folder within the same account. It
KG> won't go. Nothing happens. I try moving with the mouse, and using
KG> Ctrl-V but the message just stays there. I re-sync all folders. Same
KG> thing - no moving. So I try moving this same message to the common
KG> folder and it gets dropped (drag & drop) immediately, just like I
KG> wanted!
KG> Huh? Any guesses as to what is going on there?
I don't know what's happening there.
KG> Shut down TB, restart, refresh folders. Try moving test message
KG> (from above) from common folder to folder within account. Now it
KG> moves, although the color does get lost.
Yes.
KG> Disconnected and connected again. Turned on "Automatically connect
KG> by any command" and things seemed to start working better.
KG> At least I have a better idea of what those damn angle brackets mean.
KG> When I moved the test message to a different folder (that previously had
KG> two messages) the total message count said 2 <3> so I assume the angle
KG> brackets indicate a local (temporary) count that will get updated upon
KG> connection/sync. Sure enough, when I sync'd the folder, Total message
KG> count was simply: 3.
The angled bracket count is the number of messages in the folder
including those marked for deletion.
--
-= allie_M =- | List Moderator
PGPKeys: http://key.ac-martin.com
____________________________________
Using SB! Lite v2.03.47 on WinXP Pro (SP)
________________________________________________
Current version is 2.02.3 CE | "Using TBUDL" information:
http://www.silverstones.com/thebat/TBUDLInfo.html
