[exim-dev] [Bug 3040] New: Spoolfile error on close should n…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Exim Bugzilla
Datum:  
To: exim-dev
Betreff: [exim-dev] [Bug 3040] New: Spoolfile error on close should not lead to 250 OK
https://bugs.exim.org/show_bug.cgi?id=3040

            Bug ID: 3040
           Summary: Spoolfile error on close should not lead to 250 OK
           Product: Exim
           Version: N/A
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Mail Receipt
          Assignee: unallocated@???
          Reporter: max@???
                CC: exim-dev@???


When bad things happen on close() of -D file, it might be preferable for sender
to resend the message, and for recipient to receive a duplicate along with
possibly corrupted one, than to just deliver possibly corrupted (if existing)
message.

Looking at linux kernel source[1], there are several .flush handlers[2] defined
for
various filesystems' struct file_operations:

1) nfs, orangefs, cifs, smb2, fuse[3] -- does the flushing and returns the
result
2) ecryptfs, overlayfs -- calls flush for underlying file
3) f2fs -- always returns 0

Some filesystems may want to delay persisting data to the underlying storage
for as long as possible. In the generic case there are paths when flush handler
is never called at all (i.e. mmap()/edit/munmap()), but one may write a
filesystem tied specifically to a fixed version of exim. It could even remove
local dentries for the message files once exim is done with receiving them, and
do some locking on its own. This will allow storing spool files on a
replicated storage cluster and externally managing the queue, but demands
careful testing on upgrades in return.

I have implemented a sufficiently broken fuse fs[4] that allows to reproduce
the error on spoolfile close scenario. It needs more love, doesn't even have
readdir() support yet, nor a correct enough setattr() implementation, and
supports up to 100 inodes. I can iterate on it if requested, but this can
trigger the issue nontheless.

-----

[1] git grep -P '\.flush\s+?=' fs/

[2] explicitly called in filp_flush() in close() syscall implementation

[3]
https://github.com/libfuse/libfuse/blob/05b696edb347dc555f937c1439ffda6a1c40416e/include/fuse_lowlevel.h#L603

[4]
https://github.com/darkwrat/errclosefs/tree/72b8f575fcdc139bc30be52dacc85029588ebbe3

--
You are receiving this mail because:
You are on the CC list for the bug.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/