Hi Eric,
The RFC pretty doesn't specifically refer to the SEEN flag in reference
to READ_ONLY state. But it does say that:
If the client is not permitted to modify the mailbox but is
permitted read access, the mailbox is selected as read-only,
It doesn't specifically define READ-ONLY and what is and is not
included. But unless there are
some extenuating circumstances that I didn't come across, I think it's
safe to assume that when
the mailbox is open in READ-ONLY state, nothing should be changed,
including the SEEN flag.
But I'll admit I'm not intimately familiar with the RFC. I was
initially just hoping one of the
developers of JAMES 3 would be able to confirm that READ-ONLY should
include the SEEN flag state.
If the developer says that there is actually a reason why SEEN should
not fall under READ-ONLY state,
I'll just figure a way to work around it. But assuming READ-ONLY can be
interpreted using the classic
definition, and the SEEN state should NOT be modified when READ-ONLY,
then I believe there is a bug.
I can provide a test case.
Is it better just to provide some java source for the test case that can
be compiled into an
executable jar? Or do you prefer the compiled/built jar? If that's the
case, how do I deliver
it to you?
Alternatively, I have the entire J3 source. But there are a ton of
packages and java files and I'm not
that familiar with the code. If you can tell me the java class where
the SEEN flag is set/cleared,
it'd probably be faster for me to just look at the code and see if I can
see what is happening.
The initial question is.... 'should' SEEN come under READ-ONLY and not
be changed in READ-ONLY state?
If so, we can proceed with figuring out why it does not appear to be
behaving correctly.
Thanks.
Jerry
On 6/20/2014 12:27 AM, Eric Charles wrote:
Hi Jerry,
Thank for joining and sorry for the laaaaate answer.
The best way to tackle this is to point the rfc section where you think
james does not behave as expected. You could also upload a simple test
case that shows this.
Eric
On 05/18/2014 10:06 PM, Jerry Malcolm wrote:
I am desperately trying to figure out a way to access a message without
having the MAIL_IS_SEEN flag set. I have some background server apps
that need to scan folders and do various automated maintenance tasks. I
do not want unread mail to be marked as seen just because the utility
happened to pass over it. Yet I can't seem to stop it from happening.
I saw some posts on IMAP forums that said this was the way IMAP worked.
Really? There is absolute NO WAY to scan a folder and look at messages
in a background utility and maintain the MAIL_IS_SEEN state if it hasn't
"really" been seen by the user?
I have a test case that verifies what is happening:
-- direct SQL query to JAMES_Mail record in db to check MAIL_IS_SEEN
(initially = 0)
-- folder.open(Folder.READ_ONLY);
-- message = ((UIDFolder)folder).getMessageByUID( uid );
-- direct SQL query to JAMES_Mail record in db to check MAIL_IS_SEEN (
changed to 1)
I figured that if I opened the folder in READ_ONLY mode, then, by
definition of the term READ_ONLY I would not have 'change' authority,
and therefore the MAIL_IS_SEEN flag would not be affected. No
difference. Even opening a folder in READ_ONLY mode causes all of the
mail to be set to 'SEEN'.
Am I missing something really obvious here? I can't believe there is no
benign way to scan a folder without JAMES automatically deciding that
all mail has now been 'seen'.
Am I totally misunderstanding READ_ONLY mode of folders? Is this a bug
in JAMES? Is there a totally different way to access a message via a
Java program WITHOUT having JAMES auto-set it to 'seen'? Or am I
basically out of luck?
Thanks.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4592 / Virus Database: 3986/7797 - Release Date: 07/04/14
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
