| Age | Commit message (Collapse) | Author |
|---|
|
`open` is not as side effect free as I had imagined - i.e. if the flag `O_TRUNC` is passed it truncates the file contents alongside opening the file descriptor. In practice this is done by _emacs_ prior to writing the new file content and as such needs to be intercepted so we can start tracking the file before it is changed.
Interposing `open` required some changes to make the library work without including `fcntl.h`. This header not only defines some of the flags we require to check if a library call actually is able to change files but also defines the `open` library function.
While implementing this change I noticed that the function interpositions implemented in C++ actually need to be declared as `external "C"` so their names do not get wrangled during compilation. I suspect that this was previously implicitly done for e.g. `mmap` and `write` by the included C standard library headers. However this did not work for `open` which is why all function interpositions are now explicitly declared external.
End result: _emacs_ file changes are now tracked correctly.
|
|
|
|
All lines starting with `#` are interpreted as comments
|
|
The library may be provided with a new-line separated list of regular expressions via the newly introduced `CHANGE_LOG_IGNORE_PATTERN_PATH`.
Any proposed tracking path that is matched by any of the provided patterns is excluded from change reporting. This functionality uses the Standard's regular expression parsing functionality and as such doesn't introduce any new dependencies. If no file path is provided or the provided file path is unreadable all paths will be tracked.
`change` was adapted to set `CHANGE_LOG_IGNORE_PATTERN_PATH` to `.change_log_ignore` which means that it will by default exclude any patterns provided via this file in the current working directory.
An example for such a file customized for hiding _vim_'s internal write
logic may look as follows:
[0-9]+
[^~]*~
[.*\.viminfo
.*\.swp
Note that this is implemented in a fashion where it is not guaranteed that the full _canonical_ path is checked against the patterns. It remains to be decided if this is enough for all common use cases of this new functionality.
`tracking::PathMatcher` lacks any explicit thread synchronization - according to my current knowledge this should not be necessary as we are only ever reading the private `std::vector<std::regex>` instance.
If invalid regular expressions are provided they are silently ignored.
|
|
|
|
|
|
|
|
|
|
Relying on `diff` for storing the pre-change content did not work out as it opens the file descriptors to soon and only reads the first block of pre-change file content until the remaining content is actually required. This obviously led to problems when tracking actually changing files.
|
|
This obviously leads to synchronizing syscalls that would otherwise happen in parallel. Luckily the goal of this library is to monitor file changes performed by single, user facing applications and as such it doesn't matter if some operations are slightly slower.
|
|
|
|
|
|
Prevents the same file being tracked multiple times due to relative input paths.
|
|
While the file arguments remain fixed the actual `diff` application and its output style can be changed using the `CHANGE_LOG_DIFF_CMD` environment variable.
|
|
|
