| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
(If you drop a FileWatcher, the thread that makes it works will
exit.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2696#note_3145971
|
| |
|
|
| |
Events of type `Any` now get discarded by the event handler.
|
| |
|
|
|
| |
This enables us to catch "rescan" events, regardless of their underlying
`EventKind`.
|
| |
|
|
|
|
|
|
| |
Without this, setting `watch_configuration = true` results in endless
config reloading due to arti accessing the config (which triggers an
access event, which in turn, triggers a config reload, and so on).
Closes #1794
|
| | |
|
| |
|
|
|
|
|
| |
When testing, compare the contents of the files too, not just their
mtime Otherwise, because the polling backend detects changes based on
mtime, if the test creates/writes files too fast, it will fail to notice
changes (this can happen, for example, on a tmpfs).
|
| |
|
|
|
|
|
|
|
| |
The default is 30s, which feels a bit too long.
Also, when testing, we use a much shorter interval.
This is meant to be a temporary solution, so we hard-code the interval
rather than make it configurable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inotify.
On windows and platforms that support inotify (i.e. linux and android),
we continue using the recommended watcher. On platforms that use kqueue,
we switch to a polling watcher to work around a [notify bug] that
manifests when using a non-recursive watcher to watch a directory.
This commit is best reviewed with `git diff --ignore-all-space`.
Closes #1644
[notify bug]: https://github.com/notify-rs/notify/issues/644
|
| | |
|
| |
|
|
|
| |
This type will soon become platform-dependent, so I am preemptively
adding a type alias.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
`FileWatcher::watch_file` can be used with arbitrary paths.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Sometimes it's useful to know what files/directories are being watched.
For example, the descriptor publisher needs to know in order to figure
out if it needs to update the watcher in response to changes in the
config.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also fixes a couple of issues with the previous implementation:
* it enables you to watch for more than just one file/extension per
directory (each directory now has a list of filters. If any of the
filters apply to the path contained in the notify::Event, the
`FilterWatcher` notifies the listeners
* it removes the list watched files from `FileWatcher`. This makes
things a lot simpler to grok: essentially, the file watcher only
ever watches directories, notifying if an "interesting" file was
changed (in our case, the interesting files are files that have a
relevant extension, such as `.auth`, or specific configuration
files, as specified by `ConfigurationSources`).
|
| |
|
|
|
| |
This will soon grow more complex, so I am preemptively moving it out of
`start_watching`.
|
| |
|
|
|
| |
We don't need this variant anymore, because sighup is now handled
separately from `FileWatcher` events.
|
| |
|
|
| |
The `FileWatcher` now uses a `postage::watch` channel under the hood.
|
| |
|
|
|
| |
The event handler will soon be made async, so we need a handle to the
runtime.
|
|
|
For the most part, this is just code motion.
The only change here is that `prepare` is no longer a method on
`FileWatcher`. This decouples `FileWatcher` from `ConfigurationSources`,
enabling us to use it to watch files and directories that aren't
configuration.
|