I noticed that deliverquota was exiting with return value 0 even when the
user in question was over quota, and tracked the problem down to the fact
that the return value for close(2) wasn't getting checked.
According to the linux close(2) man page (and the tests I've run) this
causes problems:
NOTES
Not checking the return value of close is a common but nevertheless
serious programming error. File system implementations which use
techniques as ``write-behind'' to increase performance may lead to
write(2) succeeding, although the data has not been written yet.
The error status may be reported at a later write operation,
but it is guaranteed to be reported on closing the file. Not
checking the return value when closing the file may lead to silent
loss of data. This can especially be observed with NFS and disk
quotas.
A successful close does not guarantee that the data has been
successfully saved to disk, as the kernel defers writes. It is not
common for a filesystem to flush the buffers when the stream is
closed. If you need to be sure that the data is physically
stored use fsync(2) or sync(2), they will get you closer to that
goal (it will depend on the disk hardware at this point).
Should fsync(2) be called after the file is written as well?
----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin UF/CISE Department |
| E314D CSE Building Phone (352) 392-1499 |
| [EMAIL PROTECTED] http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
