In directories that have files being created and removed constantly, you will see that type of behavior since the directory may have many (hundreds or thousands) files and if you go to ls or du, the mail program may have already sent some of the mail out and removed the file. The command you tried then goes to get the information about the file and can not.
since IMAP went down, the file list has been static.
even if it was still 'flowing', i dont think du would grab a file that doenst exist even if it did a microsecond earlier. so in any case, du or ls in a normally functioning system would never read directories so sloppily.
i was really counting on a filesystem error, but fsck ran clean... d'oh
A while ago I had a problem with the internal file table in an HP-UX system. The file table (I think) is an internal kernel table that the OS is maintaining for all it's inodes - or something like that.
When the file table became full up all sorts of weird things started happening to my system and they were not restricted to (what looked like) file system errors.
The problem was the system was running out of inodes it could use and maintain in the file system. The number of inodes can be configured on a HP-UX as a kernel parameter and I would imagine that it could be on other flavours of Unix too. You might try increasing this parameter.
In my system the inodes usage was the result of a directory structure which went to too many levels. This structure was associated with data storage by processing date. When the data was finished with, the data files were removed, but the directories were left behind. Thus, the disk space was reclaimed but not necessarily all the inodes. To solve this I had a pruning process written which would remove empty directories from this directory structure and therefore reclaim the inodes.
This may or may not be the cause of your problems but it won't hurt to check how your diretories are organised; it is always useful to audit disk usage from time to time!