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

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

Dembe <da...@de...> writes:

> We hadn't spotted this and so presumably our .fetchids file hasn't been
> updated. However, we've also not had any errors in the logs saying that
> fetchmail couldn't update the .fetchids file (our system is stable so we
> don't run fetchmail with any -v 's). Shouldn't this perhaps be put forward
> as a change for a next version so that if fetchmail doesn't have access
> to the .fetchids file, a warning error is logged (even if the debug
> options aren't being explicitly enabled)?

David,

fetchmail should be doing exactly that, log and print on standard error
messages like "Cannot open fetchids file ... for writing" or "Cannot
rename fetchids file ... to ..." and the like. I've checked this, it
works for me in 6.3.2-rc1.

The problem only matters for system-wide installs that pass an UIDL file
to fetchmail that is in a directory where the fetchmail user has no
write permission.  End-user installs and system-wide installs that leave
the default --idfile are unaffected by the change, as these have write
permission in their respective home directory.

I issued the report since Debian is known to put the UID file in a
directory that the fetchmail user cannot write, so they're going to fail
when they upgrade.

Note the error messages will appear localized when fetchmail is started
with LANG or LC_MESSAGES environment variables set.

HTH,

-- 
Matthias Andree