Eric,
No worries - appreciate the keepalive ;)
Meanwhile, I was thinking on about the character-selection issue. I
really wonder if there's much point in making it a configurable
property, since there'd only be one very specific use-case for needing
to do so, and I can't see what reason anyone would have to need to
choose which character to substitute on Windows. It might be better
for wider interop if it was just specified arbitrarily.
In fact, if the chosen character is a semicolon, no bespoke
OS-detection code is even needed: it could simply set itself to
java.io.File.pathSeparator, which gives you a colon on *nix and a
semicolon on Windows.
The only possible gotcha I can see with this is the scenario where the
server is running on *nix, but the WinMailDir is on a SMB share ...
but I bet that opens up a much larger can of worms anyway.
Just some thoughts ... others welcome.
Robin Bankhead
Quoting Eric Charles <e...@apache.org>:
Sorry for this late answer. You will get my answer in the coming days.
On 03/09/13 12:59, Robin Bankhead wrote:
Hi Eric,
Apologies, you're right - that was the wrong bit of output I posted.
The scenarios that cause problems are:
1. Downloading an unseen message (I think this is what the previous
output was) fails (but then succeeds when the client is closed and
reopened).
2. Moving a message (including deletion, i.e. moving to Trash) fails
resulting in a copy in both source and destination folders.
3. If deletion is done via marking T then expunging on exit, this also
fails in the same manner.
There are two places I can identify the IOException being thrown in
different scenarios:
<apache-james-mailbox-trunk>\trunk\maildir\src\main\java\org\apache\james\mailbox\maildir\MaildirFolder.java:900
(MaildirFolder.delete())
<apache-james-mailbox-trunk>\trunk\maildir\src\main\java\org\apache\james\mailbox\maildir\mail\MaildirMessageMapper.java:219
(MaildirMessageMapper.updateFlags())
Below these calls the stacks were almost identical (IIRC; I've gone and
deleted the other one, cleverly).
I'm a bit lost on where to go from there though: should I just comb
further up the stacktrace and look for streams that aren't closed? I
realise there is concurrency involved so do I need to be looking at
other points in the code? What would be the entry-point for e.g. a
move-message-to-folder operation? Just in the maildir code, or beyond?
(Incidentally I'm not sure if I was clear on this point before, but as
far as I can tell there are no other Windows processes handling the
message files. I learned that Explorer can erroneously lock files so
I've kept it away from them, and Process Explorer isn't showing any
other handles on them from other processes.)
Thanks,
Robin Bankhead
Quoting Eric Charles <e...@apache.org>:
That's really good news.
I am not sure you fail on move. In the stacktrack you gave (yes, java
like hiding lines), the SEEN flag is set but the file renaming fails.
'..\var\store\maildir\mydomain.co.uk\wibble\cur\1377463834.cd32e9d983446360.MEBBE,S=2284;2,'
after copy to
'..\var\store\maildir\mydomain.co.uk\wibble\cur\1377463834.cd32e9d983446360.MEBBE,S=2284;2,S'
JAVA File.delete behaves differently on Windows and Linux
http://markmail.org/message/5onrj3rahwz3b3sw
So yes, you should find what is keeping the handles/locks and see if
you can close it.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
