| Message ID | af6f57ab3e6d61036cd969f5fd9256200313aaa9.1708658300.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | FSMonitor edge cases on case-insensitive file systems | expand |
"Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Jeff Hostetler <jeffhostetler@github.com> > > Move the call to invalidate the untracked cache for the FSEvent > pathname into the two helper functions. > > In a later commit in this series, we will call these helpers > from other contexts and it safer to include the UC invalidation > in the helper than to remember to also add it to each helper > call-site. > > Signed-off-by: Jeff Hostetler <jeffhostetler@github.com> > --- > fsmonitor.c | 26 +++++++++++++++++++------- > 1 file changed, 19 insertions(+), 7 deletions(-) Thanks. The steps in this iteration makes this move much less confusing to me than in the previous one. We used to call one of "handle path with/without trailing slash" functions and then called the invalidation. Now the invalidation happens in these "handle path" functions. The unexplained change in behaviour is that we used to do the rest of "handle path" and invalidation was done at the end. Now we do it upfront. I think the "rest" works solely based on what is in the main in-core index array (i.e. the_index.cache[] aka active_cache[]) and affects only what is in the in-core index array, while untracked_cache_invalidate*() works solely based on what is in the untracked cache extension (i.e. the_index.untracked) and affects only what is in there, so the order of these two does not matter. Am I correct? Or does it affect correctness or performance or whatever in any way? IOW, is there a reason why it is better to do the invalidation first and then doing the "rest" after (hence this patch flips the order of two to _improve_ something)? Thanks.
On 2/23/24 12:36 PM, Junio C Hamano wrote: > "Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: Jeff Hostetler <jeffhostetler@github.com> >> >> Move the call to invalidate the untracked cache for the FSEvent >> pathname into the two helper functions. >> >> In a later commit in this series, we will call these helpers >> from other contexts and it safer to include the UC invalidation >> in the helper than to remember to also add it to each helper >> call-site. >> >> Signed-off-by: Jeff Hostetler <jeffhostetler@github.com> >> --- >> fsmonitor.c | 26 +++++++++++++++++++------- >> 1 file changed, 19 insertions(+), 7 deletions(-) > > Thanks. The steps in this iteration makes this move much less > confusing to me than in the previous one. We used to call one of > "handle path with/without trailing slash" functions and then called > the invalidation. Now the invalidation happens in these "handle path" > functions. > > The unexplained change in behaviour is that we used to do the rest > of "handle path" and invalidation was done at the end. Now we do it > upfront. I think the "rest" works solely based on what is in the > main in-core index array (i.e. the_index.cache[] aka active_cache[]) > and affects only what is in the in-core index array, while > untracked_cache_invalidate*() works solely based on what is in the > untracked cache extension (i.e. the_index.untracked) and affects > only what is in there, so the order of these two does not matter. > > Am I correct? > > Or does it affect correctness or performance or whatever in any way? > IOW, is there a reason why it is better to do the invalidation first > and then doing the "rest" after (hence this patch flips the order of > two to _improve_ something)? > > Thanks. The ce_flags invalidation and the untracked-cache invalidation are independent (as far as I could tell) and it doesn't matter which order we do them. Moving the UC to the start of the function was an attempt to avoid the usual "goto the bottom" or the need to guard against early "return" statements that were present in some of the original code (or my various refactorings). Moving it to the top just let me get it out of the way and not have to contrive things. I'll update the commit message. Thanks Jeff
diff --git a/fsmonitor.c b/fsmonitor.c index 2787f7ca5d1..2f58ee2fe5a 100644 --- a/fsmonitor.c +++ b/fsmonitor.c @@ -188,6 +188,16 @@ static void handle_path_without_trailing_slash( { int i; + /* + * Mark the untracked cache dirty for this path (regardless of + * whether or not we find an exact match for it in the index). + * Since the path is unqualified (no trailing slash hint in the + * FSEvent), it may refer to a file or directory. So we should + * not assume one or the other and should always let the untracked + * cache decide what needs to invalidated. + */ + untracked_cache_invalidate_trimmed_path(istate, name, 0); + if (pos >= 0) { /* * We have an exact match for this path and can just @@ -249,6 +259,15 @@ static void handle_path_with_trailing_slash( { int i; + /* + * Mark the untracked cache dirty for this directory path + * (regardless of whether or not we find an exact match for it + * in the index or find it to be proper prefix of one or more + * files in the index), since the FSEvent is hinting that + * there may be changes on or within the directory. + */ + untracked_cache_invalidate_trimmed_path(istate, name, 0); + if (pos < 0) pos = -pos - 1; @@ -274,13 +293,6 @@ static void fsmonitor_refresh_callback(struct index_state *istate, char *name) } else { handle_path_without_trailing_slash(istate, name, pos); } - - /* - * Mark the untracked cache dirty even if it wasn't found in the index - * as it could be a new untracked file. (Let the untracked cache - * layer silently deal with any trailing slash.) - */ - untracked_cache_invalidate_trimmed_path(istate, name, 0); } /*