From: Wietse Venema (no email)
Date: Fri Aug 01 2003 - 15:52:00 EDT
Matthias Andree:
> (Wietse Venema) writes:
>
> >> I think using cscope to figure the full list of rename() and link() is
> >> safe enough, ultimately, there'd be one function sync_rename() and one
> >> sync_link() and these functions would be the only ones that call
> >> rename() or link().
> >
> > This is not robust. Postfix will change and there is no guarantee
> > that today's cscope result will be valid tomorrow.
>
> Of course not. There is no guarantee that tomorrow's Postfix doesn't
> contain sprintf rather than vsprintf either.
I will not reply to such a silly suggestion.
> So what's the reason to
> refuse it?
See above.
> In fact, Postfix does not call link() today, but it calls the
> sane_link() wrapper to work around non-idempotence of the wire methods
> NFS offers. rename is called from four places:
>
> 0 fsstone.c rename_file 66 if (rename(old_path, new_path))
> 1 remove.c REMOVE 69 return (rename(path, vstring_str(dest)));
> 2 postconf.c edit_parameters 472 if (rename(temp, path) < 0)
> 3 sane_rename.c sane_rename 49 if (rename(from, to) >= 0)
>
> again, you see almost everything goes through sane_rename.
Let's not mess up error suppression semantics with synchronous
update semantics.
The sane_rename() etc. routines exist to suppress spurious error
results. Their use does not at all mean that those operations must
complete before the call returns.
By the way, mkdir needs to be synchronous too, because Postfix will
create missing parent and parent-parent directories if it has to.
So your sync_mkdir() would have to invoke sane_mkdir() etc.
Wietse
|
|
|