OK, I probably should have done this 6 months ago.. but it seems that OCFS2 simply doesn't allow hard links across different directories.
defiant ~ $ mkdir 1 2 defiant ~ $ touch 1/a defiant ~ $ ls 1/ a defiant ~ $ ln 1/a 2/a ln: failed to create hard link '2/a' => '1/a': No such file or directory Which leaves me in the awkward position of courier-imap not working on OCFS2 out of the box :-( Thanks D On 10/02/15 19:41, Dan Goodliffe wrote: > Hello all, > I'm after a little help... and maybe reporting a bug... it's an odd one > at best. I posted a while ago on Gentoo forums, but got no response (I > wasn't surprised, original post here > https://forums.gentoo.org/viewtopic-t-995518-highlight-courierimap.html) > > Nothing has really changed since then, so this is basically a copy of > that posting.... > > > Some background: Some time ago, I swapped out /home on GlusterFS to > /home on primary/primary OCFS2 on DRBD setup. All seemed well at first. > Everything appeared to work, everything was fast, I was a happy man. > > Then recently I noticed that some emails were going missing, but > couldn't spot a pattern. > > What I've found is a problem which I think lies in OCFS2 or in > courier-imapd. It only appears to show itself when a mail client > (Thunderbird in my case, by messages filters, which is why I hadn't > noticed) tries to move an email from one IMAP account to my IMAP > account. What appears to happen is that the new mail message is > successfully created in ~/.maildir/tmp and not moved to ~/.maildir/cur. > I couldn't find any errors logged by courier anywhere and ignored it for > a while... then I noticed this: > Code: > > Jul 14 13:20:08 defiant kernel: (courier-imapd,20893,1):ocfs2_link:790 > ERROR: status = -2 > > A little bit of digging in the courier source and I found this function.... > Code: > > int maildir_movetmpnew(const char *tmpname, const char *newname) > { > if (link(tmpname, newname) == 0) > { > unlink(tmpname); > return 0; > } > > if (errno != EXDEV) > return -1; > > /* AFS? */ > > return rename(tmpname, newname); > } > > Which on the face of it seems to be more complicated than needs be and > expects problems on AFS. So in the spirit of testing, I changed the > function to be: > Code: > > int maildir_movetmpnew(const char *tmpname, const char *newname) > { > return rename(tmpname, newname); > } > > Normal operation has now returned. > While I can see what's happening in that function... I don't get why it > needs to be so complicated in the first place (I presume there's a good > reason, but if simple rename works on AFS, why not for everything else?) > and I don't see why my change would fix it. My gut feeling is there is a > race condition in OCFS2 that link/unlink suffer from and that rename > does not. > > Can anyone should some light on this? Anyone else tried courier-imap on > OCFS2? > > <snip> > Any thoughts very welcome. I'm planning on raising this upstream, but > I'm genuinely not sure which upstream to go with! > </snip> > I'm going courier upstream first :-) > > Thanks in advance. > Dan > > p.s. At the time, that would have v4.15... I'm about to upgrade to v4.16 > but that function remains unchanged. > -- 'rascal' Dan Goodliffe dan.goodli...@randomdan.homeip.net 07970 523693 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
