Your message dated Mon, 27 Oct 2025 14:19:46 -0700
with message-id <4341402.xgC2nNFu4n@soren-desktop>
and subject line courier-mta: leavs empty files in ~/Maildir/tmp/, if user is
overquota
has caused the Debian Bug report #612626,
regarding courier-mta: leavs empty files in ~/Maildir/tmp/, if user is overquota
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
612626: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612626
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: courier-mta
Severity: normal
Hi,
it looks courier do not unlink files it create but write failed.
This happens for example when user have filled its
filesystem quota, but still not reached inode limit.
Thus user can create files and directories, but
cannot generally use more space in files itself.
(I'm using ext3 over nfs4).
It would be useful if courier will detect that:
- file in tmp was created successfully,
- first write returned error, of any kind.
Then in such condition close file, ignore error (on write or close),
unlink temporary file, and return error to the connected smtp client
Eventually errors be interpreted to return appropriate
error message to the sending side (i.e. mapping EIO or ENOSPC
to generic messages, to not leak any details which could be in
errno message), and to loging purpose (based on errno message).
Some errors of course can be because courier does something
very wrong (i.e. passing read-only file descriptor to write),
but I assume normally all this will not happen.
Most normal error will be due to the transient problem (i.e. EINTR),
or because of system limits (like EMFILE, and even in such situation
it is more probably that open/create will fail than write).
Impossible errors (like EPERM on write) should also be handled
the same way, but of course it is probably an OS fault here.
So in all cases it will be safer to perform this
rollback (there was nothing yet written to file, what can go wrong?).
And handle few cases (ENOSPC would sufficie) to given
proper message (like "No free space available"), and rest mapping
to generic error (like "IO Error")
Thanks.
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to pl_PL.utf8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
I am going to close this bug report as there was no response to my previous
email. If anyone is still experiencing this issue, please feel free to reopen
this bug report.
--
Soren Stoutner
[email protected]
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
