Re: [PATCH 09/12] fsmonitor: refactor non-directory callback

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 4163 bytes --]

On Tue, Feb 13, 2024 at 08:52:18PM +0000, Jeff Hostetler via GitGitGadget wrote:
> From: Jeff Hostetler <jeffhostetler@github.com>
> 
> Refactor the fsmonitor_refresh_callback_unqualified() code
> to try to use the _callback_slash() code and avoid having
> a custom filter in the child cache-entry scanner.
> 
> On platforms that DO NOT annotate FS events with a trailing
> slash, if we fail to find an exact match for the pathname
> in the index, we do not know if the pathname represents a
> directory or simply an untracked file.  Pretend that the pathname
> is a directory and try again before assuming it is an untracked
> file.
> 
> Signed-off-by: Jeff Hostetler <jeffhostetler@github.com>
> ---
>  fsmonitor.c | 59 +++++++++++++++++++++++++++++++----------------------
>  1 file changed, 35 insertions(+), 24 deletions(-)
> 
> diff --git a/fsmonitor.c b/fsmonitor.c
> index 73e6ac82af7..cb27bae8aa8 100644
> --- a/fsmonitor.c
> +++ b/fsmonitor.c
> @@ -287,41 +287,52 @@ static int my_callback_dir_name_hash(
>  	return nr_in_cone;
>  }
>  
> -static void fsmonitor_refresh_callback_unqualified(
> +/*
> + * The daemon sent an observed pathname without a trailing slash.
> + * (This is the normal case.)  We do not know if it is a tracked or
> + * untracked file, a sparse-directory, or a populated directory (on a
> + * platform such as Windows where FSEvents are not qualified).
> + *
> + * The pathname contains the observed case reported by the FS. We
> + * do not know it is case-correct or -incorrect.
> + *
> + * Assume it is case-correct and try an exact match.
> + *
> + * Return the number of cache-entries that we invalidated.
> + */
> +static int fsmonitor_refresh_callback_unqualified(
>  	struct index_state *istate, const char *name, int len, int pos)
>  {
> -	int i;
> -
>  	my_invalidate_untracked_cache(istate, name, len);
>  
>  	if (pos >= 0) {
>  		/*
> -		 * We have an exact match for this path and can just
> -		 * invalidate it.
> +		 * An exact match on a tracked file. We assume that we
> +		 * do not need to scan forward for a sparse-directory
> +		 * cache-entry with the same pathname, nor for a cone
> +		 * at that directory. (That is, assume no D/F conflicts.)
>  		 */
>  		istate->cache[pos]->ce_flags &= ~CE_FSMONITOR_VALID;
> +		return 1;
>  	} else {
> +		int nr_in_cone;
> +		struct strbuf work_path = STRBUF_INIT;
> +
>  		/*
> -		 * The path is not a tracked file -or- it is a
> -		 * directory event on a platform that cannot
> -		 * distinguish between file and directory events in
> -		 * the event handler, such as Windows.
> -		 *
> -		 * Scan as if it is a directory and invalidate the
> -		 * cone under it.  (But remember to ignore items
> -		 * between "name" and "name/", such as "name-" and
> -		 * "name.".
> +		 * The negative "pos" gives us the suggested insertion
> +		 * point for the pathname (without the trailing slash).
> +		 * We need to see if there is a directory with that
> +		 * prefix, but there can be lots of pathnames between
> +		 * "foo" and "foo/" like "foo-" or "foo-bar", so we
> +		 * don't want to do our own scan.
>  		 */
> -		pos = -pos - 1;
> -
> -		for (i = pos; i < istate->cache_nr; i++) {
> -			if (!starts_with(istate->cache[i]->name, name))
> -				break;
> -			if ((unsigned char)istate->cache[i]->name[len] > '/')
> -				break;
> -			if (istate->cache[i]->name[len] == '/')
> -				istate->cache[i]->ce_flags &= ~CE_FSMONITOR_VALID;
> -		}
> +		strbuf_add(&work_path, name, len);
> +		strbuf_addch(&work_path, '/');
> +		pos = index_name_pos(istate, work_path.buf, work_path.len);
> +		nr_in_cone = fsmonitor_refresh_callback_slash(
> +			istate, work_path.buf, work_path.len, pos);
> +		strbuf_release(&work_path);
> +		return nr_in_cone;

I didn't spot any users of this return value, and Junio also mentioned
this in a preceding patch for a different function. Would it make sense
to introduce this return value as-needed in a later patch so that the
reader isn't left wondering why it's changed now?

Patrick

>  	}
>  }
>  
> -- 
> gitgitgadget
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]