Cross-platform filesystem notification library for Rust

Add file-system notifications via this library for Rust

Notify

.

Caution! This is unstable code!

You likely want either the latest 4.0 release or 5.0.0-pre.11.

(Looking for desktop notifications instead? Have a look at notify-rust or alert-after!)

  • incomplete Guides and in-depth docs
  • API Documentation
  • Crate page
  • Changelog
  • Earliest supported Rust version: 1.47.0

As used by: alacritty, cargo watch, cobalt, docket, mdBook, pax, rdiff, rust-analyzer, timetrack, watchexec, xi-editor, and others.

Installation

[dependencies]
crossbeam-channel = "0.4.0"
notify = "5.0.0-pre.11"

Usage

The examples below are aspirational only, to preview what the final release may have looked like. They may not work. Refer to the API documentation instead.

use notify::{RecommendedWatcher, RecursiveMode, Result, watcher};
use std::time::Duration;

fn main() -> Result<()> {
    // Automatically select the best implementation for your platform.
    // You can also access each implementation directly e.g. INotifyWatcher.
    let mut watcher = watcher(Duration::from_secs(2))?;

    // Add a path to be watched. All files and directories at that path and
    // below will be monitored for changes.
    watcher.watch("/home/test/notify", RecursiveMode::Recursive)?;

    // This is a simple loop, but you may want to use more complex logic here,
    // for example to handle I/O.
    for event in &watcher {
        match event {
            Ok(event) => println!("changed: {:?}", event.path),
            Err(err) => println!("watch error: {:?}", err),
        };
    }

    Ok(())
}

With a channel

To get a channel for advanced or flexible cases, use:

let rx = watcher.channel();

loop {
    match rx.recv() {
        // ...
    }
}

To pass in a channel manually:

let (tx, rx) = crossbeam_channel::unbounded();
let mut watcher: RecommendedWatcher = Watcher::with_channel(tx, Duration::from_secs(2))?;

for event in rx.iter() {
    // ...
}

With precise events

By default, Notify issues generic events that carry little additional information beyond what path was affected. On some platforms, more is available; stay aware though that how exactly that manifests varies. To enable precise events, use:

use notify::Config;
watcher.configure(Config::PreciseEvents(true));

With notice events

Sometimes you want to respond to some events straight away, but not give up the advantages of debouncing. Notice events appear once immediately when the occur during a debouncing period, and then a second time as usual at the end of the debouncing period:

use notify::Config;
watcher.configure(Config::NoticeEvents(true));

With ongoing events

Sometimes frequent writes may be missed or not noticed often enough. Ongoing write events can be enabled to emit more events even while debouncing:

use notify::Config;
watcher.configure(Config::OngoingEvents(Some(Duration::from_millis(500))));

Without debouncing

To receive events as they are emitted, without debouncing at all:

let mut watcher = immediate_watcher()?;

With a channel:

let (tx, rx) = unbounded();
let mut watcher: RecommendedWatcher = Watcher::immediate_with_channel(tx)?;

Serde

Events can be serialisable via serde. To enable the feature:

notify = { version = "5.0.0-pre.11", features = ["serde"] }

Platforms

  • Linux / Android: inotify
  • macOS: FSEvents
  • Windows: ReadDirectoryChangesW
  • FreeBSD / NetBSD / OpenBSD / DragonflyBSD: kqueue
  • All platforms: polling

FSEvents

Due to the inner security model of FSEvents (see FileSystemEventSecurity), some event cannot be observed easily when trying to follow files that do not belong to you. In this case, reverting to the pollwatcher can fix the issue, with a slight performance cost.

License

Notify was undergoing a transition to using the Artistic License 2.0 from CC Zero 1.0. A part of the code is only under CC0, and another part, including all new code since commit 3378ac5a, is under both CC0 and Artistic. When the project was to be entirely free of CC0 code, the license would be formally changed (and that would have incurred a major version bump). As part of this, contributions to Notify since would agree to release under both.

Origins

Inspired by Go's fsnotify and Node.js's Chokidar, born out of need for cargo watch, and general frustration at the non-existence of C/Rust cross-platform notify libraries.

Written by Félix Saparelli and awesome contributors.

Issues

Collection of the latest Issues

Skyxim

Skyxim

bug
0

System details

  • OS/Platform name and version: macOS Monterey 12.2
  • Rust version (if building from source): rustc --version: rustc 1.58.1 (db9d1b20b 2022-01-20)
  • Notify version (or commit hash if building from git): 5.0.0-pre.13
  • If you're coming from a project that makes use of Notify, what it is, and a link to the downstream issue if there is one:
  • Filesystem type and options:
  • On Linux: Kernel version:
  • On Windows: version and if you're running under Windows, Cygwin (unsupported), Linux Subsystem:
  • If you're running as a privileged user (root, System):
  • If you're running in a container, details on the runtime and overlay:
  • If you're running in a VM, details on the hypervisor:

What you did (as detailed as you can)

When I run the example, when the folder or file name is modified, I receive two notifications normally, but the RenameMode of both notifications is Form.

What you expected

second notify should be To

What happened

image
oumad

oumad

bug
8

System details

  • OS/Platform name and version: Microsoft Windows 10 Entreprise Version10.0.19042 build 19042
  • Rust version : 1.56.1
  • Notify version : 4.0.17
  • Filesystem type and options: NTFS, Windows Server, (by Huawei)
  • I have read/write access + ability to give others read/write access
  • Tested running both normal and as administrator

What you did (as detailed as you can)

Trying to recursively watch a shared directory using even just the example code provided in the repo.

What you expected

To get notified for all the changes (create/delete/modified...) in the directory I choose and all it's subdirectories.

What happened

Changes on the root of the watched directory get detected, but not changes in the nested directories. This problem is specific to this one shared directory (Huawei). For example I tested in both another shared directory from another windows 10 machine and I had no issue. I tested on a synology NAS (mounted again from my windows 10 machine) and no issue. I know this issue will be hard to reproduce in other environments, but I wonder if you might have an idea what could be causing it, and if there is a way to by pass that? like is there a way to force poll watching in windows for example ?

morenol

morenol

4

System details

  • OS/Platform name and version: Ubuntu 20.04
  • Rust version (if building from source): rustc --version: rustc 1.58.0 (02072b482 2022-01-11)
  • Notify version (or commit hash if building from git): 0faae4139f4aff5f2a07c7e2d8c41ee181367183

I am trying to use notify to keep track of changes in files but they are symlinks to regular files. I noticed that when using symlinks to directories everything works as expected since walkdir iterates follows the symlinks and call add_watch on them but the symbolic links to files are being ignored and in any place of the code we are calling add_watch.

What you did (as detailed as you can)

I have this:

---> README.md ---> a.d/ ---------> a.txt ----------> b (-> ../README.md)

And I used this crate to track events on a/. If I change the README.md content I dont get any events

What you expected

I would expect that any file that is linked by a symlink should be tracked

What happened

I dont get any events on files pointed by symlinks

I think that we could solve this issue if we change filter_dir to also allow symlinks when they point to regular files

https://github.com/notify-rs/notify/blob/0faae4139f4aff5f2a07c7e2d8c41ee181367183/src/inotify.rs#L560

sempervictus

sempervictus

15

System details

  • OS/Platform name and version: Linux 5.10.90
  • Rust version (if building from source): 1.57
  • Notify version (or commit hash if building from git): 15.0.0-pre3

What you did (as detailed as you can)

Using a bunch of tokio::spawn(async move calls, i'm seeing the last in the series never complete. Upon digging into the GH issues for Tokio i found this little gem which seems to say that crossbeam breaks tokio in exactly the way i'm seeing it break. The thing is, i'm not even using crossbeam in my code, i'm using tokio's unbounded channels but the presence of crossbeam is breaking things. When i make the tokio channel bounded it breaks completely - no recv() occurs. Removing notify from the codebase fixes the problem but its a critical piece of the tool being written. Specifically when sending 4 items into a channel of PathBufs i see all 4 being recv()d (i print them out at that point) with the result of the recv being passed to a tokio::spawn(async move which then prints the PathBuf again. However, only 3 of those 4 actually print from inside the spawned thread - the last one (always, it seems) never fires - in line with the bug referenced above.

What you expected

Expect every Tokio spawned task to fire all the time

What happened

Some compilations produce a working binary, and others, with no source changes but a cargo clean produce binaries which omit the last execution of the loop running off the tokio::mspc channel's receiver (the data is recv'd but the spawn call goes off into oblivion and never prints or completes). Sometimes using the variables inside the thread make it fire (like printing them a bunch of times), but something is breaking the scheduler (most likely crossbeam).

WingDust

WingDust

0

System details

  • OS/Platform name and version:Windows 10
  • Rust version (if building from source): rustc --version:rustc 1.54.0 (a178d0322 2021-07-26)
  • Notify version (or commit hash if building from git):5.0.0-pre.13
  • If you're coming from a project that makes use of Notify, what it is, and a link to the downstream issue if there is one:
  • Filesystem type and options:
  • On Linux: Kernel version:
  • On Windows: version and if you're running under Windows, Cygwin (unsupported), Linux Subsystem:
  • If you're running as a privileged user (root, System):
  • If you're running in a container, details on the runtime and overlay:
  • If you're running in a VM, details on the hypervisor:

What you did (as detailed as you can)

I follow the notify/examples/monitor_raw.rs to watch a directory code like

What you expected

I want rename event be one event when trigger rename,

What happened

As now When rename trigger will have Modify(Name(From)) and Modify(Name(To)) two Event

WingDust

WingDust

os-windows
6

System details

  • OS/Platform name and version: Windows 10
  • Rust version (if building from source): rustc --version:rustc 1.54.0 (a178d0322 2021-07-26)
  • Notify version (or commit hash if building from git): 5.0.0-pre.13 and 4. 0.17
  • If you're coming from a project that makes use of Notify, what it is, and a link to the downstream issue if there is one:
  • Filesystem type and options:
  • On Linux: Kernel version:
  • On Windows: version and if you're running under Windows, Cygwin (unsupported), Linux Subsystem:
  • If you're running as a privileged user (root, System):
  • If you're running in a container, details on the runtime and overlay:
  • If you're running in a VM, details on the hypervisor:

What you did (as detailed as you can)

When i use notify watch directory on Windows, the path is posix style like "G:/Feature/" Return Event 's path will like "G:/Feature/\\22.mp4"

this is what i test on 5.0.0-pre.13

a remove event will print

changed: Event { kind: Remove(Any), paths: ["G:/Feature/\\22.mp4"], attr:tracker: None, attr:flag: None, attr:info: None, attr:source: None }

because posix path also work with notify on Windows,but OsString::from_wide(encoded_path) will return windows style path like Feature\\22.mp4

4.0.17 is same .

So Should add a Note to README When use posix path on Windows.

What you expected

What happened

emilk

emilk

os-mac
2

System details

  • Intel MacBook running macOS BIgSur 11.6
  • Using APFS
  • rustc --version: 1.57.0
  • Notify version: latest main

What you did (as detailed as you can)

  • Watch for changes in a directory using FsEventWatcher.
  • Create a file with touch foo.
  • Create a hard-link using ln foo bar

What you expected

I expect to get an Event for both actions.

What happened

Only the creation of foo is reported. Nothing happens when creating the hardlink-file (bar).

Investigation

I added some logging inside of src/fsevent.rs and I get no callback when creating the hard-link, so this is likely a problem with FSEvent, or how it is being used. I tried looking for some extra flag to pass into FSEventStreamCreate, but couldn't find anything suitable.

0xpr03

0xpr03

enhancement
0

We currently don't allow directly passing a Send + Sync EventHandler in a transparent fashion if its required for the underlying backend. See impl Watcher of ReadDirectoryChangesWatcher and #360 .

A neat improvement would be to allow passing it transparently but also auto Arc-Mutexing it otherwise.

jhscheer

jhscheer

bug
0

System details

  • OS/Platform name and version: Linux (5.13.15-200.fc34.x86_64)
  • Rust version (if building from source): rustc --version: 1.54.0
  • Notify version (or commit hash if building from git): 4.0.17 / 5.0.0-pre.13

What you did (as detailed as you can)

Run above code to monitor testfile, then run:

Both the raw PollWatcher and the debounced PollWatcher panic if a watched file is remove and recreated.

Edit: Same issue exists on 5.0.0-pre.13:

What you expected

What happened

MiniaczQ

MiniaczQ

os-windows
7

Hello, this is a question/discussion, but just to give a full context of my problem I've partially filled out the bug form.

System details

  • OS: Windows 10 v10.0.19043
  • Rust version: 1.56.0-nightly
  • Notify version: 5.0.0-pre.11

What you did (as detailed as you can)

I'm working on an utility app that needs to read minecraft's client log. I cannot read from stdout for irrelevant reasons, so I need to look into a file called 'latest.log', which is a text file.

  1. I tried opening the file in read mode, to read all the logs as they come.
  2. Later I created a watcher that tracks any changes in that file.

What you expected

  1. Since the file is actively being modified, I expected to never find the EOF in it and just get stuck on reading, until the client closes the file.

  2. I expected every addition to the file to report an event.

What happened

  1. The file had EOF, so it stopped reading after it caught up the first time.

  2. No events were reported. Further testing revealed that polling would work. Also, opening (and closing, no r/w) the file in an asynchronous loop, while the watcher is running also resulted in modifications being detected.

The file seems to get modified only when I try to access it (by opening it or trying to read metadata).

My thoughts and questions

The results appears like a problem with FSEvents (polling works, but not events), but since I'm running Windows, that'd be the FileSystemAudit. Does this problem even exists on Windows? If so, is there a way to get the permission for the file and use the event system? If not, is there any other way I can evade polling? (maybe a way to open the file as a device? So that I don't get EOF, until the client actually closes it)

There are moment where I need extremely quick responses and I'd rather not poll multiple times per second. If I cannot get this to work with events I'll probably create a variable period poll-watcher.

If there is anything else I can provide that would help with this lmk.

nx-jackal

nx-jackal

bug
0

System details

  • OS/Platform name and version: Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal

  • Rust version (if building from source): rustc --version:

  • rustc 1.47.0

  • Notify version (or commit hash if building from git): 4.0.17 installed via cargo

  • Filesystem type and options:

  • Ext4

  • On Linux: Kernel version:

  • Linux jackal 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

What you did (as detailed as you can)

Monitor a folder for filesystem events. However, symlink creation generates event with strange random filename

What you expected

Symlink creation event should show normal symlink filename. Remove symlink event works fine though.

What happened

I've tried creating a symlink called "second" pointing "aaa". Instead of getting an event with a path like "/home/jackal/test/second" I receive an event with the path like "/home/jackal/test/CuS4NDCI".

Thanks.

rrichardson

rrichardson

1

I have a use case where I want to process all files in a directory at startup time, then process any new files that are added during runtime. It would simplify my code quite a bit if I could use the same event stream for both.

From an API perspective, this would be a simple, non-breaking change. We could add an existing enumeration to EventKind, (something like Existing) and also add a new enumeration to Config (maybe ListExistingFiles(bool) )

If this is desirable, I am happy to provide an implementation.

erickt

erickt

enhancement
3

More follow on to #306, what do you think about marking all the EventKind enum types, and child enums as #[non_exhaustive]? Looking at both the fsevents flags and inotify manpage, it looks like the event type expands over time, so I think it'd be worth allowing new event types to be added over time.

I think this would be preferable over using Event::set_info, at least in most cases, since it can be difficult for downstream users to understand the stability guarantee of the info strings, especially since they are not documented.

erickt

erickt

enhancement
1

As part of developing #307, I realized it might be worth hiding the public fields in Event as part of 5.0.0. This would allow the underlying object to be extended with new attributes without breaking existing clients. I have a proof-of-concept of this change in https://github.com/erickt/notify/tree/hide-fields that's built upon #307 that I can push up after we address #306.

queer

queer

enhancement
10

#255 is related but is NOT the same thing.

I have a use-case in which I want to watch my entire $HOME. However, due to WINE prefixes and other circumstances, it turns out I have a bunch of symlinks into / by accident. This is causing the inotify watcher to recurse through the entire directory tree and error out when it can't set a watch on something owned by root and not world-readable. It'd be nice to be able to filter out symlinks that specifically go to /.

Beyond this, it would be nice to be able to make something equivalent to ignore to ex. not open watches on a node_modules folder or other ignored files.

If this is worth adding, I'll try to put together a PR for this.

lambda2501

lambda2501

bug
6

System details

  • OS/Platform name and version: GNU/Linux Void Linux Kernel 5.10.14_1
  • Rust version (if building from source): rustc --version: 1.48.0
  • Notify version (or commit hash if building from git): 4.0.15
  • If you're coming from a project that makes use of Notify, what it is, and a link to the downstream issue if there is one: Using Zola, issue found in this topic
  • Filesystem type and options: ext4
  • On Linux: Kernel version: 5.10.14_1

What you did (as detailed as you can)

Because the use of the serve command from zola didn't work, I tried to look at the notify dependency as suggested by a zola user:

  • using this piece of code from rust documentation:

get this error (full backtrace):

What you expected

I was expected it working

What happened

I got an error as described.

skorokithakis

skorokithakis

needs info
1

Currently, the debouncer actually only collapses events. It would be useful if the debouncer could ignore all events until the timeout occurred, and then reported all of them at once.

This is useful for letting the changes "settle", ie have an idle period before attempting to e.g. copy files to a remote server.

oOBoomberOo

oOBoomberOo

enhancement
3

System details

  • OS/Platform name and version: Windows 10
  • Rust version (if building from source): 1.46.0
  • Notify version (or commit hash if building from git): 5.0.0-pre.3
  • Filesystem type and options: NTFS

What you did (as detailed as you can)

I have a basic file watcher function which watch for any event from some path recursively:

What you expected

The log message will print a helpful message of what exactly happened with the file/folder under that path.

What happened

The log message will almost always print an Any variant of CreateKind, RemoveKind, and ModifyKind. Only when I try renaming some file that it manage to print the ModifyKind::Name variant.

Wouldn't this be quite useless for a more complex situation where you need to know what exactly happened to the file/folder?

casey

casey

bug
4

System details

  • OS: MacOS v10.14.6
  • Rust version: rustc 1.45.0 (5c1f21c3b 2020-07-13)
  • Notify version: v4.0.15 from crates.io
  • Filesystem: APFS (Encrypted)

Description

I encountered this issue using cargo-watch, but I think it's a notify issue. Forgive me if that's not the case! I'm using cargo-watch v0.7.5 built from source from crates.io, which uses watchexec v1.14.0, which uses notify v4.0.15.

I have a static site generator, and my watch command was running in a loop. The path update debug message looked like this:

A bunch of similar paths were also printed. All the files were static assets in the in directory, and they were files that I didn't think I was modifying.

The static assets were all being copied from the in directory to an ignored out directory with the following code:

When I replaced the above with the functionally equivalent, cargo-watch stopped looping:

I also tried the following, which is even closer, and which also stopped the looping:

I dug into std::fs::copy to see if I could find anything suspicious, but I couldn't find anything. For reference, std::fs::copy is defined here.

This is super strange, since I think the above snippets are mostly identical, and none of them seem to modify the assets in in.

I'm trying to get dtrace working to see if I can see any difference in system calls, but in the mean time I thought I'd create this issue and see if it was known.

bollian

bollian

enhancement
0

I've noticed that notify spawns a thread for each watcher object. This isn't a good fit for the app I'm writing, which really just spends all its time watching a few directories, and terminates on a SIGINT or the like. For this, I really want the code that receives and debounces events to be on the main thread and to simply block on the event source. Would it be possible to allow me to run the notify internal logic in this way?

What would be exceptional, though not strictly necessary, is the ability to integrate this into an async runtime. For example, it's trivially easy to combine the inotify and smol crates to suddenly have an event source sit along side a networked application since inotify allows access to the underlying raw file descriptor. This could be useful if I expand my app in the future.

I guess what I really want this crate to be is a translation layer that turns native fs events into something somewhat consistent across platforms and less so the runtime it is today. I'm even willing to manually call a poll function since I can deal with writing delay logic myself.

stuhood

stuhood

enhancement
2

Hey folks! Have been happily using 5.0.0.pre2 for a few months now.

Our use of the notify crate is symlink aware, so before running read_link, we ensure that we use this crate's API to watch it. The behavior of read_link is to return the destination of a symlink, even if it is dead, and we rely on that in order to track the existence of the symlink and watch it in case it changes.

But on linux, the notify crate's inotify implementation currently doesn't set IN_DONT_FOLLOW:

... which means that the attempt to watch a dead symlink fails.


To work around this, I have a small patch to the crate that currently just... unconditionally sets IN_DONT_FOLLOW (which is clearly not landable as is), and then another landable patch to avoid stating things unnecessarily: #256. But I'd like to help ensure that this can be supported upstream, and would be interested in suggestions for how it could be included into the API as an optional toggle.

A global toggle per-watcher would be sufficient for our usecase, but it's also possible that some callers would prefer this on a watch-by-watch basis. Alternatively, perhaps a Watcher::symlink_watch method that was the spiritual equivalent of https://doc.rust-lang.org/std/path/struct.Path.html#method.symlink_metadata... ie, not reading/watching through a symlink if it existed?

Mimerme

Mimerme

bug
4

System details

  • Microsoft Windows 10 Pro 10.0.19041 Build 19041
  • notify = "5.0.0-pre.3"
  • Running Windows Subsystem for Linux (WSL)
  • WSL: Linux DESKTOP-HHHHH 4.4.0-19041-Microsoft #1-Microsoft Fri Dec 06 14:06:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

What you did (as detailed as you can)

Running this code and setting to a specific text file and then editing it in vim and saving it only prints the first 3 events, but nothing after that.

What you expected

Editing it in vim and saving it only prints the first 3 events for the first save, but nothing after that. I expected that making additional edits and saving them would print more events, but this did not happen.

What happened

Only the first 3 events when editing with vim are printed.

Additional Notes

When setting to the text file's directory, the program actually prints that events where the attribute contains the specific file when writing multiple times with vim. I think there's an issue in the library with filtering out specific events.

tokahuke

tokahuke

discussion
11

Release candidate 2 is already 5 months in the air. Isn't is time to release it as "final" already?

pickfire

pickfire

good first issue
2

Since there can only be one RecommendedWatcher, why do we still need to explicitly specify the type? Taken from the new docs.

Not sure if we can remove the explicit type for RecommendedWatcher.

bluejekyll

bluejekyll

0

System details

  • OS/Platform name and version: Linux 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

  • Rust version (if building from source): rustc 1.41.0 (5e1a79984 2020-01-27)

  • Notify version (or commit hash if building from git):

  • Filesystem type and options: ext4 rw,user,exec 0 0

  • On Linux: Kernel version: 4.15.0-74-generic

  • If you're running as a privileged user (root, System): no

  • If you're running in a container, details on the runtime and overlay: no

  • If you're running in a VM, details on the hypervisor: no

What you did (as detailed as you can)

When hard-linking one file to another, i.e. touch test && ln test test_link, and placing a monitor on the file, the last file being registered is always returned regardless of which is modified.

What you expected

The correct file path is returned in the list of files based on the path modified.

What happened

Only the last registered path is returned. I did some investigation. I think this is a limitation of inotify in Linux. Performing the same test on macOS provided the expected results (I m pretty sure). After investigating it appears that both hard-linked files when registered with return the same WatchDescriptor::id. This results in the watches (path -> WatchDescriptor) and then paths (WatchDescriptor -> Path) overwriting each other. This matches the behavior I've noticed, where when an event comes into EventLoop::handle_inotify only the most recently registered file path is notified.

I initially started down a path to experiment with changing the EventLoop::paths from HashMap<WatchDescriptor, PathBuf> to HashMap<WatchDescriptor, Vec<PathBuf>> but this creates confusing output in multi-path events, such as rename. Has anyone else seen this? Any thoughts on a path forward?

Versions

Find the latest versions by id

5.0.0-pre.13 - Nov 21, 2021

5.0.0-pre.13 (2021-09-07)

  • Fix: Add path information to inotify and kqueue watch/unwatch errors #354
  • Fix: Delete dbg call from kqueue.rs #357

5.0.0-pre.12 - Aug 17, 2021

5.0.0-pre.12 (2021-08-18)

  • CHANGE: Move creation of watcher into trait #345
  • CHANGE: Add EventHandler trait to replace EventFn #346
  • FIX: Fix build failure on x86_64-unknown-netbsd #347

5.0.0-pre.11 - Jul 23, 2021

5.0.0-pre.11 (2021-07-22)

  • FEATURE: Add Kqueue backend for use on BSD #335
  • CHANGE: Change EventFn to take FnMut #333
  • CHANGE: Make Watcher object safe #336
  • FIX: Join thread in fseven on shutdown #337
  • FIX: Only check for ENOSPC on inotify_add_watch in inotify #330
  • FIX: Free context when stream is deallocated in fsevent #329
  • DOCS: Fix missing comma in docs #340

5.0.0-pre.10 - Jun 04, 2021

5.0.0-pre.10 (2021-06-04)

  • FIX: Make StreamContextInfo Send to fix soundness issue #325

5.0.0-pre.9 - May 26, 2021

5.0.0-pre.9 (2021-05-21)

  • DEPS: Upgrade fsevent-sys dependency to 4.0 #322
  • CHANGE: Remove dependency on fsevent. #313
  • FIX: Correct the return type for CFRunLoopIsWaiting to be Boolean #319
  • CHANGE: Hide fsevent::{CFRunLoopIsWaiting,callback}, fix clippy lint warnings #312
  • FIX: Fix some clippy lints #320

4.0.17 - May 13, 2021

4.0.17 (2021-05-13)

  • FIX: Don't crash on macos when creating & deleting folders in rapid succession #303

5.0.0-pre.8 - May 12, 2021

5.0.0-pre.8 (2021-05-12)

  • HOTFIX: Fix breaking change in fsevent-sys in minor version destroying builds #316
  • FIX: Don't crash on macos when creating & deleting folders in rapid succession #302
  • FIX: Remove anymap, and replace event attributes with an opaque type. #306

v5.0.0-pre.7 - Apr 15, 2021

5.0.0-pre.7 (2021-04-15)

  • FIX: Display proper error message when reaching inotify limits on linux #285
  • FIX: Fix leaks on Windows #298

v4.0.16 - Apr 15, 2021

4.0.16 (2021-04-14)

  • FIX: Report events promptly on Linux, even when many occur in rapid succession. #268
  • FIX: Fix leaks on Windows and debounce module. #288
  • FIX: Display proper error message when reaching inotify limits on linux. #290

v5.0.0-pre.6 - Feb 20, 2021

  • FIX: Handle interrupted system call errors from mio #281

v5.0.0-pre.5 - Jan 28, 2021

5.0.0-pre.5 (2021-01-28)

  • RUSTC: Push the minimum version to 1.47.0 #280
  • DEPS: Update inotify to 0.9 #280
  • DEPS: Update mio to 0.7 and remove mio-extras #278
  • FIX: Report events promptly on Linux, even when many occur in rapid succession. #268

v5.0.0-pre.4 - Oct 31, 2020

5.0.0-pre.4 (2020-10-31)

  • CHANGE: Avoid stating the watched path for non-recursive watches with inotify #256
  • DOCS: Fix broken link in crate documentation #260

v5.0.0-pre.3 - Jun 22, 2020

5.0.0-pre.3 (2020-06-22)

  • DEPS: Removed unused chashmap dependency #242

v4.0.15 - Jan 07, 2020

4.0.15 (2020-01-07)

  • DEPS: Update inotify to 0.7.
  • DEPS(DEV): Replace tempdir with tempfile since tempdir is deprecated.
  • DEPS: Update winapi to 0.3 and remove kernel32-sys. #232

v5.0.0-pre.2 - Jan 07, 2020

5.0.0-pre.2 (2020-01-07)

  • (Temporary): Remove event debouncing.
  • (Temporary): Remove tests.
  • CHANGE: Rewrite immediate events to use new system.
  • CHANGE: Remove Senders from watcher API in favour of EventFn #214
  • DEPS: Update inotify to 0.8. #234
  • DEPS: Update crossbeam-channel to 0.4.
  • DEPS: [macOS] Update fsevent to 2.0.1 and fsevent-sys to 3.0.0.

v2.6.1 - Oct 30, 2016

  • FIX: [Linux] Only register directories for watching.

v2.6.2 - Oct 30, 2016

  • FEATURE: [macOS] Implement Send and Sync for FsWatcher. #82
  • FEATURE: [Windows] Implement Send and Sync for ReadDirectoryChangesWatcher. #82
  • DOCS: Add example to monitor a given file or directory.

v2.6.3 - Oct 30, 2016

  • FIX: [macOS] Bump fsevents version. #91

v3.0.0 - Oct 30, 2016

  • FIX: [Windows] Fix watching files on Windows using relative paths. #90
  • FEATURE: Add debounced event notification interface. #63
  • FEATURE: [Polling] Implement CREATE and DELETE events for PollWatcher. #88
  • FEATURE: [Polling] Add ::with_delay_ms() constructor. #88
  • FIX: [macOS] Report ITEM_CHANGE_OWNER as CHMOD events. #93
  • FIX: [Linux] Emit CLOSE_WRITE events. #93
  • FEATURE: Allow recursion mode to be changed. #60, #61 breaking
  • FEATURE: Track move events using a cookie.
  • FEATURE: [macOS] Return an error when trying to unwatch non-existing file or directory.
  • CHANGE: [Linux] Remove IGNORED event. breaking
  • CHANGE: [Linux] Provide absolute paths even if the watch was created with a relative path.

Information - Updated Feb 19, 2022

Stars: 1.5K
Forks: 129
Issues: 48

Repositories & Extras

A cross-platform GUI library for Rust focused on simplicity and type-safety

Cross-platform support (Windows, macOS, Linux, and text inputs, Debug overlay with performance metrics

A cross-platform GUI library for Rust focused on simplicity and type-safety
Misc

248

A CLI tool to easily get a new project up and running by using pre-made...

A rust cross platform rust boilerplate template to get up and running quickly

A CLI tool to easily get a new project up and running by using pre-made...

HAL : Hyper Adaptive Learning

Rust based Cross-GPU Machine Learning

HAL : Hyper Adaptive Learning

A crossplatform Rust bindings for the soloud audio engine library

Supported formats: wav, mp3, ogg, flac

A crossplatform Rust bindings for the soloud audio engine library

Safe wrapper around SPIR-V Cross

Safe wrapper around SPIRV-Cross for use with Rust

Safe wrapper around SPIR-V Cross

🐏 rpmalloc-rs

Cross-platform Rust global memory allocator using rpmalloc README for a detailed description of how the allocator works, peforms, and compares with other allocators

🐏 rpmalloc-rs

Rust crate providing cross-platform information about the notebook batteries

battery provides a cross-platform unified API to a notebook batteries state

Rust crate providing cross-platform information about the notebook batteries

rust-clipboard is a cross-platform library for getting and setting the contents of the OS-level clipboard

It has been tested on Windows, Mac OSX, GNU/Linux, and FreeBSD

rust-clipboard is a cross-platform library for getting and setting the contents of the OS-level clipboard

A cross-platform GUI library for Rust focused on simplicity and type-safety

Cross-platform support (Windows, macOS, Linux, and text inputs, Debug overlay with performance metrics

A cross-platform GUI library for Rust focused on simplicity and type-safety

A cross platform Rust library for efficiently walking a directory recursively

Comes with support for following symbolic links, controlling the number of

A cross platform Rust library for efficiently walking a directory recursively

debug-here: a cross platform rust debugger hook

Debuggers are a great way to examine the state of a program

debug-here: a cross platform rust debugger hook
Facebook Instagram Twitter GitHub Dribbble
Privacy