falood/file_system
58.2
Adequate · 3 October 2026
1.2k
lines of production code
Elixir
with C, C#
1
measurement over time
What this system is
FileSystem is an Elixir library that monitors file system changes across multiple operating systems, including macOS, Windows, and various Unix-like platforms. It provides a GenServer-based API for starting watchers and subscribing to events, automatically selecting the appropriate native backend or falling back to polling. The system handles cross-platform compatibility, process lifecycle management, and event distribution to registered subscribers.
Features
Add macOS CLI and Windows inotify-win port implementations
This change introduces the native source code for the platform-specific watchers. On macOS, it adds a C-based command-line interface (\c\_src/mac\) that wraps the FSEvents API, including compatibility shims for older OS versions (10.6–10.9) and options for latency, root watching, and file-level events. On Windows, it adds a C\# implementation (\c\_src/windows\) porting the \inotifywait\ tool using \FileSystemWatcher\, supporting recursive monitoring, event filtering, and custom output formatting.
_c\src · high confidence
New file system backends for polling, Windows, and improved cross-platform support
This change introduces new file system monitoring backends: FSPoll (a cross-platform polling backend usable on any OS when explicitly configured), FSWindows (a Windows-specific backend using inotifywait.exe), and updated backends for macOS, Linux, FreeBSD, DragonFly BSD, and OpenBSD. The FSPoll backend allows users to monitor file changes via periodic polling with a configurable interval, providing a fallback for environments where native OS-specific listeners are unavailable or unsuitable. The Windows backend enables file system watching on Windows systems. The existing backends have been refined to support additional operating systems (DragonFly BSD, OpenBSD), improve path handling (including support for paths with spaces and correct path separators on Windows), and enhance process management (ensuring inotifywait processes are properly killed when the BEAM process exits). Users can now monitor file systems on a wider range of platforms and have more control over backend selection and configuration.
_lib/file\system/backends · high confidence
Behavioural changes
Introduce FileSystem module and remove ExFSWatch macro
The library now exposes a new \FileSystem\ module that provides a \start\_link/1\ API for configuring file system monitoring (including options like \:latency\ and \:backend\) and a \subscribe/1\ function for receiving events, replacing the previous \ExFSWatch\ module which is deleted. This change shifts the public interface from a macro-based setup to a standard GenServer-based supervision model, allowing users to start monitoring with explicit configuration and subscribe processes to receive file event messages.
lib · high confidence
License changed to Apache 2.0 and project renamed to FileSystem
The project license has been switched from the original BSD-style license to the Apache License 2.0. Additionally, the project has been renamed from ExFSWatch to FileSystem, and the README has been updated to reflect this new name, the new license, and updated usage instructions for the Elixir package.
(repo-wide) · high confidence
New backend selection and worker supervision logic
The library now introduces a dedicated backend selection module and a central worker process to manage file system monitoring. The new backend module automatically selects the appropriate monitoring implementation (macOS, Linux/FreeBSD/OpenBSD/DragonFly via inotify, Windows, or a polling fallback) based on the operating system, while also validating that the chosen backend supports the current platform. The new worker process acts as a GenServer that initializes the selected backend, forwards file events received from the backend's port process to all registered subscribers, and cleans up subscriber references when they terminate, ensuring robust event distribution and process lifecycle management.
_lib/file\system · high confidence
Removal of legacy config/config.exs file
The legacy config/config.exs file has been removed from the project. This file previously contained boilerplate comments and configuration for the Mix.Config module, including sample logger settings and instructions for environment-specific configuration imports. Its removal suggests a migration away from this specific configuration pattern, likely towards a newer Elixir configuration approach or a different project structure.
config · high confidence
Removal of legacy supervisor and worker processes
The \ExFSWatch.Supervisor\ and \ExFSWatch.Worker\ modules have been removed from the library. This eliminates the previous implementation that relied on a \simple\_one\_for\_one\ supervision tree and spawned external \fswatch\ processes via \Port.open\ to monitor file system changes. Users relying on these specific internal components for process management or direct worker interaction will need to adapt to the new architecture.
lib/exfswatch · high confidence
Test coverage
Added integration tests for file system event handling; Added unit tests for file-system backend options and event parsing.
Dependencies
Rename to FileSystem and upgrade Elixir requirement to 1.11
The project has been renamed from ExFSWatch to FileSystem, with the application ID changing from :exfswatch to :file\_system. The minimum supported Elixir version has been raised from 1.0 to 1.11. The build process now includes a dedicated compilation step for the native Mac file system watcher (c\src/mac/\.c) during Mix compilation, applying any provided CFLAGS and LDFLAGS. Documentation generation is now configured via the ex\_doc dependency, and the package metadata (maintainers, licenses, files) is explicitly defined for Hex publishing.
(dependencies) · high confidence
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
Score
- CAI 56 → 58 (+2.0)
- Rubric changed (rubric-2026.09.15 → rubric-2026.10.1) — scores are not directly comparable.
Lenses
- Code Health 99 → 99 (-0.1)
- Architecture 69 → 69 (+0.0)
- Maturity 45 → 46 (+1.4)
- Readiness 50 → 55 (+5.2)
- Security 100 → 100 (+0.0)
Resolved (4)
- Documentation: no architecture or design documentation (README.md)
- Documentation: no usage examples (README.md)
- Duplicated block (10 lines × 2) (lib/file_system/backends/fs_mac.ex)
- Duplicated block (15 lines × 2) (lib/file_system/backends/fs_mac.ex)
New (3)
- Duplicated block (11 lines × 2) (lib/file_system/backends/fs_mac.ex)
- Duplicated block (17 lines × 2) (lib/file_system/backends/fs_mac.ex)
- Duplicated block (8 lines × 2) (lib/file_system/backends/fs_mac.ex)
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
falood/file_system was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.
About this page
- The score is its most recent published measurement, taken on 3 October 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit f1d39e353934936520f1b1edf736ef74ad449f1c — the exact code this score is about.
- Scored under rubric-2026.10.1 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-24c657e50118.