Extending an automatically watched tree to a new directory swallowed
every error, so a reached watch limit or an unreadable directory left
part of the tree unwatched without any sign. No call of the consumer is
running at that moment, so the failures now arrive in the event stream
as InotifyEvent.watchFailed, after the event that triggered the
extension. The library watches what it can first: a reached limit ends
the attempt, an unreadable directory is skipped with its subtree, and a
directory that vanished in between is not reported.
The buffer now carries the library's own events next to the kernel's,
which keeps them in order and hides the stream's element type. The
test runner drops root's DAC capabilities so that an unreadable
directory can be tested.
A recursive watch that hit the watch limit or an unreadable directory
threw after adding watches for part of the tree, which stayed in the
instance and kept counting against the user's limit. The call now
leaves the instance as it found it.
The test needs a second instance for the check, because a repeated
watch on the same instance only updates the existing one.
The stream's element is now the enum InotifyEvent, and the struct that
describes a change to a watched item is FileSystemEvent. A queue
overflow was an event with descriptor -1 and an empty path that every
consumer had to know about; as a case, the compiler makes them handle
it. The enum is also where failed watches of a growing tree will be
reported, since no call site can catch them.
Patterns such as `.*` or `@*` are matched against an item's own name
with `fnmatch`, in the same places as excluded names: resolving a
tree, extending a watch to a directory that appears later, and
delivering events. Dependents that prune large trees can now skip
whole families of directories without listing each name.
`InotifyEventMask` took its bits from the C header, so nothing that
imported it could build outside Linux. The new `InotifyMask` product
spells out the kernel constants instead; a Linux test compares each
of them with the header. `Inotify` re-exports the module, so
existing code is unaffected.
The resolver skipped an excluded directory in its result but still
walked its subtree, so watches were installed below names such as
`.git` or `node_modules`. Exclusion now prunes the walk.
Automatic subtree watching only reacted to `CREATE`, so a directory
moved in from elsewhere stayed unwatched. It is now handled like a
created one. Items that already exist in such a directory never
produce kernel events; they are reported with the same event kind
and `synthesized` set to `true`, so consumers can treat them as
newly appeared.
A directory moved out of a watched tree kept its kernel watches, so
later changes inside it were reported under the old path. Its
watches and those of its subdirectories are now removed on
`MOVED_FROM`. Watches the kernel reports as `IGNORED` are forgotten
as well, so a reused descriptor number cannot map to a stale path.
`IN_Q_OVERFLOW` arrives with watch descriptor -1, so the path lookup
failed and the event was silently discarded. It is now delivered
with an empty path so consumers can rescan after the kernel dropped
events.
Events were buffered with `bufferingNewest(512)`, so a burst of
changes silently lost all but the newest 512 events whenever the
consumer lagged. The stream now buffers without limit, and
`init(bufferingPolicy:)` lets callers choose a bounded policy.
`deinit` closed the inotify descriptor while its dispatch source was
still active. The kernel drops the epoll registration on close, but
libdispatch keeps its own; an instance created afterwards that reuses
the descriptor number could inherit that stale state and never
receive events. Roughly one test run in three lost a single event
this way.
The reader is now cancelled in `deinit` and the descriptor closed in
its cancel handler, as libdispatch requires.
The exclusive `from: "0.3.0"` range blocked dependents that already
use swift-subprocess 1.0. Version 1.0 renamed the stdio outputs used
by the task CLI to `currentStandardOutput` and `currentStandardError`.
Properties of actors are implicitly isolated. To be able to read the
events stream from any concurrent context, we need to declare it
nonisolated. And as AsyncStream conforms to Sendable, it is safe to make
both events and the private eventStream nonisolated.
Drop Shwift: it is incompatible with musl (used by the Swift static
linking SDK), and its API is not meaningfully more concise than
Subprocess upon closer inspection.
As the development team uses both Intel and Apple Silicon Macs,
we have to get the host CPU architecture at compilation time instead of
harcoding it.
If the container has a different architecture, the guest has to be
emulated.
SwiftPM has currently a bug, that products or targets of dependencies
are taken into consideration when resolving names, regardless if they're
used or not by the root package. This stops Swift PM from working on packages,
that declare this package as a dependency and define their own TaskCLI target,
as they collide with the definitions of this package. This is resolved, by
prefixing TaskCLI with the package name.
The product collision - which causes swift run - to run this package's task
executable is resolved, by adding that product only temporarily during task
execution using task.sh.
See https://github.com/swiftlang/swift-package-manager/issues/8482
inotify exposes a /proc interface to limit kernel memory usage. If those
limits are set too low, inotify cannot add all watches. The integration
test verifies, that Inotify yields an error in that case.
For watching whole trees - a change which is upcoming - the watch
descriptor IDs will have to be managed in multiple lists. The
InotifyWatchManager encapsulates the managment logic within a nice API.
Instead of using hardcoded fixed width integers, use C integer types.
As the actual integer size of C depends on the implementation, even if
it is often 32bit, we use the C integer types to guard against cases,
where that is not the case.
Each inotify instance produces events for paths in its watch list. Each
item in the watch list is identified by its watch descriptor. Different
paths can be watched for different events.
T. R. Bernstein