On Fri, Mar 11 2022, Jeff Hostetler via GitGitGadget wrote:
> From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
>
> fixup! fsmonitor--daemon: use a cookie file to sync with file system
>
> Use implicit definitions for FCIR_ enum values.
>
> Remove const from cookie->name.
>
> Reverse if then and else branches around open() to ease readability.
>
> Document that we don't care about errors from close() and unlink().
>
> Signed-off-by: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
> ---
> builtin/fsmonitor--daemon.c | 53 +++++++++++++++++++++----------------
> 1 file changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/builtin/fsmonitor--daemon.c b/builtin/fsmonitor--daemon.c
> index 97ca2a356e5..02a99ce98a2 100644
> --- a/builtin/fsmonitor--daemon.c
> +++ b/builtin/fsmonitor--daemon.c
> @@ -109,14 +109,14 @@ static int do_as_client__status(void)
>
> enum fsmonitor_cookie_item_result {
> FCIR_ERROR = -1, /* could not create cookie file ? */
> - FCIR_INIT = 0,
> + FCIR_INIT,
> FCIR_SEEN,
> FCIR_ABORT,
> };
>
> struct fsmonitor_cookie_item {
> struct hashmap_entry entry;
> - const char *name;
> + char *name;
> enum fsmonitor_cookie_item_result result;
> };
>
> @@ -166,37 +166,44 @@ static enum fsmonitor_cookie_item_result with_lock__wait_for_cookie(
> * that the listener thread has seen it.
> */
> fd = open(cookie_pathname.buf, O_WRONLY | O_CREAT | O_EXCL, 0600);
> - if (fd >= 0) {
> - close(fd);
> - unlink(cookie_pathname.buf);
> -
> - /*
> - * Technically, this is an infinite wait (well, unless another
> - * thread sends us an abort). I'd like to change this to
> - * use `pthread_cond_timedwait()` and return an error/timeout
> - * and let the caller do the trivial response thing, but we
> - * don't have that routine in our thread-utils.
> - *
> - * After extensive beta testing I'm not really worried about
> - * this. Also note that the above open() and unlink() calls
> - * will cause at least two FS events on that path, so the odds
> - * of getting stuck are pretty slim.
> - */
> - while (cookie->result == FCIR_INIT)
> - pthread_cond_wait(&state->cookies_cond,
> - &state->main_lock);
> - } else {
> + if (fd < 0) {
> error_errno(_("could not create fsmonitor cookie '%s'"),
> cookie->name);
>
> cookie->result = FCIR_ERROR;
> + goto done;
> }
>
> + /*
> + * Technically, close() and unlink() can fail, but we don't
> + * care here. We only created the file to trigger a watch
> + * event from the FS to know that when we're up to date.
> + */
> + close(fd);
It still seems odd to explicitly want to ignore close() return values.
I realize that we do in (too many) existing places, but why wouldn't we
want to e.g. catch an I/O error here early?
