I am deploying a new mail server on James/Windows and was wondering if you think the support for WinMailDir is stable enough for a new deployment. I don't need to migrate a pile of old mail, so it's really just about stability of the running system. I can potentially debug other issues, though I don't have a proper test bed to debug your migration issue. I would prefer to run from the start with file-based mailboxes.
I can also confirm the Thunderbird issue you saw. I am seeing multiple copies of mail in the Sent folder when sending from Thunderbird. No issues with WIndows Live Mail, OSX Mail, Pegasus Mail, Incredimail, or the Android mobile email client. Please let me know how I can help. Robert On Tue, Sep 24, 2013 at 7:08 AM, Robin Bankhead <[email protected]> wrote: > Hi Eric, > > As suggested, JIRA filed as MAILBOX-199. > > FYI, the Draft-flag problem I mentioned turned out to be a red herring, the > client simply doesn't respect that flag. > > The new challenge is a failure when trying to upload a large corpus of mail > (and dir hierarchy) from another server, but I'm still looking into this - > it may be another illegal-char issue, or in name generation at high > frequency (not enough uniqueness)? I'll post more when I know more. > > Robin Bankhead > > > Quoting Eric Charles <[email protected]>: > >> Hi Robin, Thx for the follow-up. >> >> Explicitly calling System.gc can bring global bad performance, so it >> should be called only in case of windows platform. >> >> The best is to create a JIRA (if not already existing) and attach there >> your patch. >> >> On 18/09/13 22:00, Robin Bankhead wrote: >>> >>> Hi, >>> >>> An update and another patch. I've found that doing GC before attempting >>> the file move/rename operation allows it to succeed in every permutation >>> I've tried so far. The patch implements this in >>> MaildirMessageMapper.updateFlags(), giving it 5 tries (this may be >>> excessive, I dunno; next time I'll check how many tries it takes). >>> >>> NB: I switched from FileUtils.moveFile() to File.renameTo() just for the >>> sake of constructing a quick test since it has a boolean return value; I >>> did already try just drop-in replacing it (without the loop), and it >>> also failed. >>> >>> I *think* this means there's an unreleased File{In,Out}putStream lurking >>> somewhere that needs to be found but, from what I've read, I'm still not >>> sure that I can rule out Windows itself holding the lock even when >>> release() has been explicitly called, which some commentators on the >>> subject seem convinced of. >>> >>> It's still reporting all messages as Draft, so I shall busy myself >>> investigating that in the meantime. >>> >>> Regards, >>> Robin Bankhead --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
