[fetchmail-users] Re: [fetchmail-announce] fetchmail 6.3.0 contained incompatible idfile change

[Matthias A. <mat...@gm...>]

Simon Barner schrieb am 2006-01-05:

> Matthias Andree wrote:
> > Beginning with release 6.3.0, fetchmail needs not only need write access
> > to the idfile ($HOME/.fetchids), but also to the directory holding this
> > file. fetchmail 6.2.X and older versions got away if just the idfile had
> > write permission.
> > 
> > The reason is that fetchmail 6.3.0 and newer now writes the ids to a
> > temporary file, to avoid truncation of the idfile if running short of
> > diskspace; a truncated idfile might lead to many duplicate messages,
> > which might, in turn, aggravate the "low space" situation.
> 
> What about using one of the system-wide temporary directories instead?

The basic idea is: the UIDs are somewhat precious (and we have had
issues to that extent in the bug trackers). That's why I chose to write
a temporary file and atomically (i. e. rename(2)) replace the original
file. This guarantees that we'll always have the old UID file available
even if writing the new fails at some point. In unlucky situations,
6.2.5.X and older might end up with an empty ID file, would start
refetching and flooding /var/mail with dupes.

Rename(2) only works within the same device or perhaps mountpoint (some
file systems such as AFS and Coda even turn every directory into a
filesystem of its own). Besides that, I will not use directories with
public write access (/tmp, /var/tmp), these are minefields, and handling
subdirectories within them still doesn't guarantee we can rename without
truncating the output file.

Plus, creating backup files still requires write permission on the
directory...

Debian for instance uses a fetchmail user for the system wide fetchmail
daemon, home directory is /var/run/fetchmail, yet they use
/var/mail/.i-forgot-the-UIDL-name for their idfile. If they used
/var/run/fetchmail/.i-forgot-the-UIDL-name, everything would be fine. No
need for ${TMPDIR-/tmp}.

-- 
Matthias Andree