Re: [PATCH v2 14/16] fsmonitor: support case-insensitive events

> "Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> +/*
>> + * Use the name-hash to do a case-insensitive cache-entry lookup with
>> + * the pathname and invalidate the cache-entry.
>> + *
>> + * Returns the number of cache-entries that we invalidated.
>> + */
>> +static size_t handle_using_name_hash_icase(
>> +	struct index_state *istate, const char *name)
>> +{
>> +	struct cache_entry *ce = NULL;
>> +
>> +	ce = index_file_exists(istate, name, strlen(name), 1);
>> +	if (!ce)
>> +		return 0;
>> +
>> +	/*
>> +	 * A case-insensitive search in the name-hash using the
>> +	 * observed pathname found a cache-entry, so the observed path
>> +	 * is case-incorrect.  Invalidate the cache-entry and use the
>> +	 * correct spelling from the cache-entry to invalidate the
>> +	 * untracked-cache.  Since we now have sparse-directories in
>> +	 * the index, the observed pathname may represent a regular
>> +	 * file or a sparse-index directory.
>> +	 *
>> +	 * Note that we should not have seen FSEvents for a
>> +	 * sparse-index directory, but we handle it just in case.
>> +	 *
>> +	 * Either way, we know that there are not any cache-entries for
>> +	 * children inside the cone of the directory, so we don't need to
>> +	 * do the usual scan.
>> +	 */
>> +	trace_printf_key(&trace_fsmonitor,
>> +			 "fsmonitor_refresh_callback MAP: '%s' '%s'",
>> +			 name, ce->name);
>> +
>> +	untracked_cache_invalidate_trimmed_path(istate, ce->name, 0);
>> +	ce->ce_flags &= ~CE_FSMONITOR_VALID;
>> +	return 1;
>> +}
> 
> You first ask the name-hash to turn the incoming "name" into the
> case variant that we know about, i.e. ce->name, and use that to
> access the untracked cache.  Clever and makes sense.  But if we have
> ce->name, doesn't it mean the name is tracked?  Do we find anything
> useful to do in the untracked cache invalidation codepath in that
> case?
> 
> An FSmonitor event with case-incorrect pathname for a directory may
> not be this trivial, I presume, and I expect that is what the
> remainder of this patch is about.

> 
>> +
>> +/*
>> + * Use the dir-name-hash to find the correct-case spelling of the
>> + * directory.  Use the canonical spelling to invalidate all of the
>> + * cache-entries within the matching cone.
>> + *
>> + * Returns the number of cache-entries that we invalidated.
>> + */
>> +static size_t handle_using_dir_name_hash_icase(
>> +	struct index_state *istate, const char *name)
> 
> It is a bit unfortunate that here on the name-hash side we contrast
> the two helper function variants as "dir-name" vs "name", while the
> original handle_path side use "without_slash" vs "with_slash".
> 
> If I understand correctly, it is not like there are two distinct
> hashes, "name-hash" vs "dir-name-hash".  Both of these helpers use
> the same "name-hash" mechanism, and this function differs from the
> previous one in that it is about a directory, which is why it has
> "dir" in its name.  I wonder if we renamed the other one with
> "nondir" in its name, and the other without_slash and with_slash
> pair to match, e.g., handle_nondir_path() vs handle_dir_path(), or
> something like that, the resulting names for these four functions
> become easier to contrast and understand?

> 
>> +{
>> +	struct strbuf canonical_path = STRBUF_INIT;
>> +	int pos;
>> +	size_t len = strlen(name);
>> +	size_t nr_in_cone;
>> +
>> +	if (name[len - 1] == '/')
>> +		len--;
>> +
>> +	if (!index_dir_find(istate, name, len, &canonical_path))
>> +		return 0; /* name is untracked */
>> +
>> +	if (!memcmp(name, canonical_path.buf, canonical_path.len)) {
>> +		strbuf_release(&canonical_path);
>> +		/*
>> +		 * NEEDSWORK: Our caller already tried an exact match
>> +		 * and failed to find one.  They called us to do an
>> +		 * ICASE match, so we should never get an exact match,
>> +		 * so we could promote this to a BUG() here if we
>> +		 * wanted to.  It doesn't hurt anything to just return
>> +		 * 0 and go on becaus we should never get here.  Or we
>> +		 * could just get rid of the memcmp() and this "if"
>> +		 * clause completely.
>> +		 */
>> +		return 0; /* should not happen */
>> +	}
> 
> "becaus" -> "because".
> 
> If we should never get here, having BUG("we should never get here")
> would not hurt anything, either.  On the other hand, silently
> returning 0 will hide the bug under the carpet, and I am not sure it
> is fair to call it "doesn't hurt anything".

> 
>> +
>> +	trace_printf_key(&trace_fsmonitor,
>> +			 "fsmonitor_refresh_callback MAP: '%s' '%s'",
>> +			 name, canonical_path.buf);
>> +
>> +	/*
>> +	 * The dir-name-hash only tells us the corrected spelling of
>> +	 * the prefix.  We have to use this canonical path to do a
>> +	 * lookup in the cache-entry array so that we repeat the
>> +	 * original search using the case-corrected spelling.
>> +	 */
>> +	strbuf_addch(&canonical_path, '/');
>> +	pos = index_name_pos(istate, canonical_path.buf,
>> +			     canonical_path.len);
>> +	nr_in_cone = handle_path_with_trailing_slash(
>> +		istate, canonical_path.buf, pos);
>> +	strbuf_release(&canonical_path);
>> +	return nr_in_cone;
>> +}
> 
> Nice.  Do we need to give this corrected name to help untracked
> cache invalidation from the caller that called us?

> 
>> @@ -319,6 +416,19 @@ static void fsmonitor_refresh_callback(struct index_state *istate, char *name)
>>   	else
>>   		nr_in_cone = handle_path_without_trailing_slash(istate, name, pos);
>>   
>> +	/*
>> +	 * If we did not find an exact match for this pathname or any
>> +	 * cache-entries with this directory prefix and we're on a
>> +	 * case-insensitive file system, try again using the name-hash
>> +	 * and dir-name-hash.
>> +	 */
>> +	if (!nr_in_cone && ignore_case) {
>> +		nr_in_cone = handle_using_name_hash_icase(istate, name);
>> +		if (!nr_in_cone)
>> +			nr_in_cone = handle_using_dir_name_hash_icase(
>> +				istate, name);
>> +	}
> 
> It might be interesting to learn how often we go through these
> "fallback" code paths by tracing.  Maybe it will become too noisy?
> I dunno.