dovecot - Nov 2007 - unlink_directory(....Trash.NewFolder) failed: Directory not empty

I noticed the following this week.  No idea how long its been happening because
I have
not tested deleting folders hardly at all.  Steps to reproduce:

1.  Create a folder "NewFolder", click on it in thunderbird so an
index dir is created:

ls -ldi Maildir/.NewFolder/
1504062 drwx------  5 mcdouga9  egrstaff  4096 Nov 16 19:44 Maildir/.NewFolder/

ls -ldi Maildir/dovecot/boomhauer/private/indexes/.NewFolder/
4198832 drwx------  2 mcdouga9  egrstaff  4096 Nov 16 19:44
Maildir/dovecot/boomhauer/private/indexes/.NewFolder/

ls -li Maildir/dovecot/boomhauer/private/indexes/.NewFolder/
total 0
4198833 -rw-------  1 mcdouga9  egrstaff  128 Nov 16 19:44 dovecot.index.log


2.  Delete "NewFolder" which makes Thunderbird move both the folder
under Trash, and seems to
"rename" the .NewFolder index dir to .Trash.NewFolder (same inode #):
ls -ldi Maildir/.Trash.NewFolder/
1504062 drwx------  5 mcdouga9  egrstaff  4096 Nov 16 19:44
Maildir/.Trash.NewFolder/

ls -ldi Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder/
4198832 drwx------  2 mcdouga9  egrstaff  4096 Nov 16 19:44
Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder/

ls -li Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder/
total 4
4198833 -rw-------  1 mcdouga9  egrstaff  128 Nov 16 19:44 dovecot.index.log


3.  Right click on Trash folder in Thunderbird, choose "Empty Trash":

Nov 16 19:47:25 boomhauer dovecot: IMAP(mcdouga9): 
unlink_directory(/home/mcdouga9/Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder)
failed: Directory not
empty

ls -ldi Maildir/.Trash.NewFolder/
1504062 drwx------  5 mcdouga9  egrstaff  4096 Nov 16 19:44
Maildir/.Trash.NewFolder/

ls -ldi Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder/
4198832 drwx------  2 mcdouga9  egrstaff  4096 Nov 16 19:47
Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder/

ls -li Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder/
(sometimes has a .nfs.blahblah file, I think I failed to catch it quick enough
this time)

The folder dissapears from Thunderbird's view but stays on disk, and will
reappear in Thunderbird
if you collapse and re-expand the folder tree, or close and open thunderbird. 
Repeatable after more
"Empty Trash" or directly trying to delete the folder in thunderbird
from in Trash.



# 1.1.beta8: /usr/local/etc/dovecot.conf
ssl_cert_file: /usr/local/etc/apache2/ssl/mail.egr.msu.edu.pem
ssl_key_file: /usr/local/etc/apache2/ssl/mail.egr.msu.edu.pem
login_dir: /var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
verbose_proctitle: yes
first_valid_uid: 1000
first_valid_gid: 1000
mail_extra_groups: postlocal
mail_location: 
maildir:%h/Maildir:CONTROL=%h/Maildir/dovecot/private/control:INDEX=%h/Maildir/dovecot/%q/private/indexes
mmap_disable: yes
dotlock_use_excl: yes
mail_nfs_storage: yes
mail_nfs_index: yes
mail_plugins: acl fts fts_squat
mail_log_max_lines_per_sec: 0
imap_client_workarounds: delay-newmail netscape-eoh tb-extra-mailbox-sep
namespace:
  type: private
  separator: /
  inbox: yes
  list: yes
  subscriptions: yes
namespace:
  type: private
  separator: /
  prefix: mail/
  hidden: yes
  subscriptions: yes
namespace:
  type: private
  separator: /
  prefix: Mail/
  hidden: yes
  subscriptions: yes
namespace:
  type: public
  separator: /
  prefix: #shared/decs/
  location: 
maildir:/egr/mail/shared/decs:CONTROL=%h/Maildir/dovecot/public/control/decs:INDEX=%h/Maildir/dovecot/%q/public/indexes/decs
  list: yes
  subscriptions: yes
auth default:
  passdb:
    driver: pam
  userdb:
    driver: passwd
    args: system_user  socket:
    type: listen
    client:
      path: /var/spool/postfix/private/auth
      mode: 384
      user: postfix
      group: postfix
plugin:
  acl: vfile:/usr/local/etc/dovecot-acls:cache_secs=10
  fts: squat

On Fri, 2007-11-16 at 19:50 -0500, Adam McDougall wrote:
> 3.  Right click on Trash folder in Thunderbird, choose "Empty
Trash":
> 
> Nov 16 19:47:25 boomhauer dovecot: IMAP(mcdouga9): 
>
unlink_directory(/home/mcdouga9/Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder)
failed: Directory not
> empty
..
> (sometimes has a .nfs.blahblah file, I think I failed to catch it quick
enough this time)
I think that's the problem. If Thunderbird opens the mailbox in one
connection and then tries to delete it in another connection, Dovecot
still has some files open in that directory and when they're deleted
kernel goes and renames them to those .nfs* files.

I'm not sure if there's anything I can do about that, except maybe try
to give a nicer error message ("Internal error" -> "Can't
delete an open
mailbox").

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20071118/1d87b5e1/attachment-0002.bin>

On Sun, Nov 18, 2007 at 11:12:46AM +0200, Timo Sirainen wrote:

  On Fri, 2007-11-16 at 19:50 -0500, Adam McDougall wrote:
  > 3.  Right click on Trash folder in Thunderbird, choose "Empty
Trash":
  > 
  > Nov 16 19:47:25 boomhauer dovecot: IMAP(mcdouga9): 
  >
unlink_directory(/home/mcdouga9/Maildir/dovecot/boomhauer/private/indexes/.Trash.NewFolder)
failed: Directory not
  > empty
  ..
  > (sometimes has a .nfs.blahblah file, I think I failed to catch it quick
enough this time)
  
  I think that's the problem. If Thunderbird opens the mailbox in one
  connection and then tries to delete it in another connection, Dovecot
  still has some files open in that directory and when they're deleted
  kernel goes and renames them to those .nfs* files.
  
  I'm not sure if there's anything I can do about that, except maybe try
  to give a nicer error message ("Internal error" ->
"Can't delete an open
  mailbox").
  
Please don't make dovecot treat it as a bigger problem (disconnect or even
give an
error) if there is nothing that can be done to improve the situation, I
don't want my
users to complain to me because their email client gives them a loud error
because my
server is unable to delete non-empty directories.  I would bet my users
don't delete
folders very often, in fact my old server would fail folder deletion with an
error
for thunderbird clients because you cannot move a folder into a mbox Trash 
(workaround was to delete immediately).  If we delete a folder and empty trash
right
away, it will reappear later either after a reconnect or maybe if the Trash
folder
gets refreshed.  Definitely after a reconnect, the second attempt to empty Trash
works.  If I am lucky, human nature might make them wonder if they forgot to
empty
trash :) If there is no way to make all dovecot processes close all files in a
folder
to be purged from trash, on at least the same server, I guess I could settle for
the
current behavior.  If a workaround is needed to empty trash and its not too much
trouble for the user, we'll just have to document it in our knowledge base. 
Thanks
for your consideration.