I'm just in the throws of putting all my emails (in maildir format) onto the unRAID server (in a user share).  All is working well, I can read and write messages in the maildir.

 

However, I'm now attempting to get the mail fetcher to write the messages directly into the maildir.  The fetcher writes the message to tmp, then tries to link it into new, whereupon this error message is produced:

 

mpop: /mnt/user/Maildir/peter: cannot link tmp/1304240623.M036884P6430Q1.Tower to new/1304240623.M036884P6430Q1.Tower: Function not implemented

 

Is linking really not available on array drives?  I know that I've used links (which I presume are the same things) on my cache drive.

 

Wikipedia tells me this about the delivery of new mails into maildir:

The delivery process stores the message in the maildir by creating and writing to tmp/unique, and then moving this file to new/unique. The moving is commonly done by hard linking the file to new and then unlinking the file from tmp, but some implementations simply rename() it there.

 

Is there any way around this, other than persuading the fetcher to use rename rather than link?

 

My overall project is to run the mailserver (Dovecot) on the unRAID box, using mpop to fetch from my mail host.  I can then read my mail from any client, using imap.

 

If/When I get it all working satisfactorily, I'll do a little write-up and post the ready-built binaries.

I'm just in the throws of putting all my emails (in maildir format) onto the unRAID server (in a user share).  All is working well, I can read and write messages in the maildir.

 

However, I'm now attempting to get the mail fetcher to write the messages directly into the maildir.  The fetcher writes the message to tmp, then tries to link it into new, whereupon this error message is produced:

 

mpop: /mnt/user/Maildir/peter: cannot link tmp/1304240623.M036884P6430Q1.Tower to new/1304240623.M036884P6430Q1.Tower: Function not implemented

 

Is linking really not available on array drives?  I know that I've used links (which I presume are the same things) on my cache drive.

 

Wikipedia tells me this about the delivery of new mails into maildir:

The delivery process stores the message in the maildir by creating and writing to tmp/unique, and then moving this file to new/unique. The moving is commonly done by hard linking the file to new and then unlinking the file from tmp, but some implementations simply rename() it there.

 

Is there any way around this, other than persuading the fetcher to use rename rather than link?

 

My overall project is to run the mailserver (Dovecot) on the unRAID box, using mpop to fetch from my mail host.  I can then read my mail from any client, using imap.

 

If/When I get it all working satisfactorily, I'll do a little write-up and post the ready-built binaries.

Use the "disk" share.  The links should work there.    Because the user-shares are potentially spanning multiple disks, hard links will not work.

Use the "disk" share.  The links should work there.    Because the user-shares are potentially spanning multiple disks, hard links will not work.

 

That makes sense ... if only I'd thought about what is happening! 

 

The reason I want to use a user share is to avoid mail processing from failing when the physical disk fills.  I'd either have to devote a drive to the mail storage, or only share it with other data which won't expand.

 

However, I found it fairly trivial to modify mpop to use rename instead of linking/delinking.

 

Anyway, I'm on to my next problem now!  Dovecot sees the new mail, renames it into /cur but then seems to have problems serving it - I'm not sure whether the problem is in Dovecot or Thunderbird