Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replication sieve activate should be atomic #1933

Closed
brong opened this issue Apr 23, 2017 · 0 comments
Closed

replication sieve activate should be atomic #1933

brong opened this issue Apr 23, 2017 · 0 comments
Assignees
Labels
3.0 affects 3.0 3.1 affects 3.1 dev releases

Comments

@brong
Copy link
Member

brong commented Apr 23, 2017

In timsieved it's very careful to always keep a script active:

/* ok we want to do this atomically so let's
   - make <activesieve>.NEW as a hard link
   - rename it to <activesieve>
*/
result = symlink(filename, "defaultbc.NEW");
if (result) {
    syslog(LOG_ERR, "symlink(%s, defaultbc.NEW): %m", filename);
    prot_printf(conn, "NO \"Can't make link\"\r\n");
    return TIMSIEVE_FAIL;
}

result = rename("defaultbc.NEW", "defaultbc");
if (result) {
    unlink("defaultbc.NEW");
    syslog(LOG_ERR, "rename(defaultbc.NEW, defaultbc): %m");
    prot_printf(conn,"NO \"Error renaming\"\r\n");
    return TIMSIEVE_FAIL;
}
sync_log_sieve(sieved_userid);

...

In sync_support, it is not only not atomic, it has a gap while the whole file gets recompiled:

snprintf(target, sizeof(target), "%s", name);
snprintf(active, sizeof(active), "%s/%s", sieve_path, "defaultbc");
unlink(active);

#ifdef USE_SIEVE
char *bc_fname = strconcat(sieve_path, "/", target, NULL);
sieve_rebuild(NULL, bc_fname, 0, NULL);
free(bc_fname);
#endif

/* N.B symlink() does NOT verify target for anything but string validity,
 * so activation of a nonexistent script will report success.
 */
if (symlink(target, active) < 0)
    return(IMAP_IOERROR);

...

sync_support should switch to using the same logic that timsieved does to ensure there's always an active script.

@elliefm elliefm added 3.0 affects 3.0 3.1 affects 3.1 dev releases labels Apr 24, 2017
elliefm added a commit that referenced this issue Apr 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.0 affects 3.0 3.1 affects 3.1 dev releases
Projects
None yet
Development

No branches or pull requests

2 participants