2017-09-22 18:35:40 +02:00
|
|
|
#ifndef FSMONITOR_H
|
|
|
|
#define FSMONITOR_H
|
|
|
|
|
2018-08-15 19:54:05 +02:00
|
|
|
#include "cache.h"
|
|
|
|
#include "dir.h"
|
|
|
|
|
2017-09-22 18:35:40 +02:00
|
|
|
extern struct trace_key trace_fsmonitor;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the fsmonitor index extension and (if configured) restore the
|
|
|
|
* CE_FSMONITOR_VALID state.
|
|
|
|
*/
|
2019-04-29 10:28:14 +02:00
|
|
|
int read_fsmonitor_extension(struct index_state *istate, const void *data, unsigned long sz);
|
2017-09-22 18:35:40 +02:00
|
|
|
|
|
|
|
/*
|
2017-11-09 20:58:10 +01:00
|
|
|
* Fill the fsmonitor_dirty ewah bits with their state from the index,
|
|
|
|
* before it is split during writing.
|
|
|
|
*/
|
2019-04-29 10:28:14 +02:00
|
|
|
void fill_fsmonitor_bitmap(struct index_state *istate);
|
2017-11-09 20:58:10 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Write the CE_FSMONITOR_VALID state into the fsmonitor index
|
|
|
|
* extension. Reads from the fsmonitor_dirty ewah in the index.
|
2017-09-22 18:35:40 +02:00
|
|
|
*/
|
2019-04-29 10:28:14 +02:00
|
|
|
void write_fsmonitor_extension(struct strbuf *sb, struct index_state *istate);
|
2017-09-22 18:35:40 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Add/remove the fsmonitor index extension
|
|
|
|
*/
|
2019-04-29 10:28:14 +02:00
|
|
|
void add_fsmonitor(struct index_state *istate);
|
|
|
|
void remove_fsmonitor(struct index_state *istate);
|
2017-09-22 18:35:40 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Add/remove the fsmonitor index extension as necessary based on the current
|
|
|
|
* core.fsmonitor setting.
|
|
|
|
*/
|
2019-04-29 10:28:14 +02:00
|
|
|
void tweak_fsmonitor(struct index_state *istate);
|
2017-09-22 18:35:40 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Run the configured fsmonitor integration script and clear the
|
|
|
|
* CE_FSMONITOR_VALID bit for any files returned as dirty. Also invalidate
|
|
|
|
* any corresponding untracked cache directory structures. Optimized to only
|
|
|
|
* run the first time it is called.
|
|
|
|
*/
|
2019-04-29 10:28:14 +02:00
|
|
|
void refresh_fsmonitor(struct index_state *istate);
|
2017-09-22 18:35:40 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the given cache entries CE_FSMONITOR_VALID bit. This should be
|
|
|
|
* called any time the cache entry has been updated to reflect the
|
|
|
|
* current state of the file on disk.
|
|
|
|
*/
|
mark_fsmonitor_valid(): mark the index as changed if needed
Without this bug fix, t7519's four "status doesn't detect unreported
modifications" test cases would fail occasionally (and, oddly enough,
*a lot* more frequently on Windows).
The reason is that these test cases intentionally use the side effect of
`git status` to re-write the index if any updates were detected: they
first clean the worktree, run `git status` to update the index as well
as show the output to the casual reader, then make the worktree dirty
again and expect no changes to reported if running with a mocked
fsmonitor hook.
The problem with this strategy was that the index was written during
said `git status` on the clean worktree for the *wrong* reason: not
because the index was marked as changed (it wasn't), but because the
recorded mtimes were racy with the index' own mtime.
As the mtime granularity on Windows is 100 nanoseconds (see e.g.
https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times),
the mtimes of the files are often enough *not* racy with the index', so
that that `git status` call currently does not always update the index
(including the fsmonitor extension), causing the test case to fail.
The obvious fix: if we change *any* index entry's `CE_FSMONITOR_VALID`
flag, we should also mark the index as changed. That will cause the
index to be written upon `git status`, *including* an updated fsmonitor
extension.
Side note: Even though the reader might think that the t7519 issue
should be *much* more prevalent on Linux, given that the ext4 filesystem
(that seems to be used by every Linux distribution) stores mtimes in
nanosecond precision. However, ext4 uses `current_kernel_time()` (see
https://unix.stackexchange.com/questions/11599#comment762968_11599; it
is *amazingly* hard to find any proper source of information about such
ext4 questions) whose accuracy seems to depend on many factors but is
safely worse than the 100-nanosecond granularity of NTFS (again, it is
*horribly* hard to find anything remotely authoritative about this
question). So it seems that the racy index condition that hid the bug
fixed by this patch simply is a lot more likely on Linux than on
Windows. But not impossible ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-24 14:23:48 +02:00
|
|
|
static inline void mark_fsmonitor_valid(struct index_state *istate, struct cache_entry *ce)
|
2017-09-22 18:35:40 +02:00
|
|
|
{
|
mark_fsmonitor_valid(): mark the index as changed if needed
Without this bug fix, t7519's four "status doesn't detect unreported
modifications" test cases would fail occasionally (and, oddly enough,
*a lot* more frequently on Windows).
The reason is that these test cases intentionally use the side effect of
`git status` to re-write the index if any updates were detected: they
first clean the worktree, run `git status` to update the index as well
as show the output to the casual reader, then make the worktree dirty
again and expect no changes to reported if running with a mocked
fsmonitor hook.
The problem with this strategy was that the index was written during
said `git status` on the clean worktree for the *wrong* reason: not
because the index was marked as changed (it wasn't), but because the
recorded mtimes were racy with the index' own mtime.
As the mtime granularity on Windows is 100 nanoseconds (see e.g.
https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times),
the mtimes of the files are often enough *not* racy with the index', so
that that `git status` call currently does not always update the index
(including the fsmonitor extension), causing the test case to fail.
The obvious fix: if we change *any* index entry's `CE_FSMONITOR_VALID`
flag, we should also mark the index as changed. That will cause the
index to be written upon `git status`, *including* an updated fsmonitor
extension.
Side note: Even though the reader might think that the t7519 issue
should be *much* more prevalent on Linux, given that the ext4 filesystem
(that seems to be used by every Linux distribution) stores mtimes in
nanosecond precision. However, ext4 uses `current_kernel_time()` (see
https://unix.stackexchange.com/questions/11599#comment762968_11599; it
is *amazingly* hard to find any proper source of information about such
ext4 questions) whose accuracy seems to depend on many factors but is
safely worse than the 100-nanosecond granularity of NTFS (again, it is
*horribly* hard to find anything remotely authoritative about this
question). So it seems that the racy index condition that hid the bug
fixed by this patch simply is a lot more likely on Linux than on
Windows. But not impossible ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-24 14:23:48 +02:00
|
|
|
if (core_fsmonitor && !(ce->ce_flags & CE_FSMONITOR_VALID)) {
|
|
|
|
istate->cache_changed = 1;
|
2017-09-22 18:35:40 +02:00
|
|
|
ce->ce_flags |= CE_FSMONITOR_VALID;
|
|
|
|
trace_printf_key(&trace_fsmonitor, "mark_fsmonitor_clean '%s'", ce->name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear the given cache entry's CE_FSMONITOR_VALID bit and invalidate
|
|
|
|
* any corresponding untracked cache directory structures. This should
|
|
|
|
* be called any time git creates or modifies a file that should
|
|
|
|
* trigger an lstat() or invalidate the untracked cache for the
|
|
|
|
* corresponding directory
|
|
|
|
*/
|
|
|
|
static inline void mark_fsmonitor_invalid(struct index_state *istate, struct cache_entry *ce)
|
|
|
|
{
|
|
|
|
if (core_fsmonitor) {
|
|
|
|
ce->ce_flags &= ~CE_FSMONITOR_VALID;
|
dir.c: ignore paths containing .git when invalidating untracked cache
read_directory() code ignores all paths named ".git" even if it's not
a valid git repository. See treat_path() for details. Since ".git" is
basically invisible to read_directory(), when we are asked to
invalidate a path that contains ".git", we can safely ignore it
because the slow path would not consider it anyway.
This helps when fsmonitor is used and we have a real ".git" repo at
worktree top. Occasionally .git/index will be updated and if the
fsmonitor hook does not filter it, untracked cache is asked to
invalidate the path ".git/index".
Without this patch, we invalidate the root directory unncessarily,
which:
- makes read_directory() fall back to slow path for root directory
(slower)
- makes the index dirty (because UNTR extension is updated). Depending
on the index size, writing it down could also be slow.
A note about the new "safe_path" knob. Since this new check could be
relatively expensive, avoid it when we know it's not needed. If the
path comes from the index, it can't contain ".git". If it does
contain, we may be screwed up at many more levels, not just this one.
Noticed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-07 10:21:40 +01:00
|
|
|
untracked_cache_invalidate_path(istate, ce->name, 1);
|
2017-09-22 18:35:40 +02:00
|
|
|
trace_printf_key(&trace_fsmonitor, "mark_fsmonitor_invalid '%s'", ce->name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|