hannobraun / inotify-sys

Low-level inotify bindings for the Rust programming language

inotify-sys

Low-level inotify bindings for the Rust programming language. This crate's main purpose is to serve as the base for inotify-rs, the idiomatic Rust wrapper around inotify. Unless you're sure you specifically need this crate, please use inotify-rs instead.

License

Copyright (c) Hanno Braun and contributors

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

inotify-sys's Issues

Cannot build on windows 10

Hello,
have an issue building on Windows machine.

Here is the error:

$ cargo test
   Updating crates.io index
   Compiling libc v0.2.48
   Compiling inotify-sys v0.1.4-dev (C:\WORK\SOC\inotify-sys)
  --> src\lib.rs:58:37
   |
58 | pub const IN_CLOEXEC: c_int = libc::O_CLOEXEC;
   |                                     ^^^^^^^^^ not found in `libc`
error[E0425]: cannot find value `O_NONBLOCK` in module `libc`
  --> src\lib.rs:69:38
   |
69 | pub const IN_NONBLOCK: c_int = libc::O_NONBLOCK;
   |                                      ^^^^^^^^^^ not found in `libc`

error[E0425]: cannot find value `O_CLOEXEC` in module `libc`
  --> src\lib.rs:58:37
   |
58 | pub const IN_CLOEXEC: c_int = libc::O_CLOEXEC;
   |                                     ^^^^^^^^^ not found in `libc`

error[E0425]: cannot find value `O_NONBLOCK` in module `libc`
  --> src\lib.rs:69:38
   |
69 | pub const IN_NONBLOCK: c_int = libc::O_NONBLOCK;
   |                                      ^^^^^^^^^^ not found in `libc`

error: aborting due to 2 previous errors

My toolchain:

active toolchain
----------------

nightly-2019-01-14-x86_64-pc-windows-msvc (default)
rustc 1.33.0-nightly (2fadb0a16 2019-01-13)

I downloaded the libc and I build it without problems.
I have no issue building on linux.

Thanks in advance for help.

Mario

Please add LICENSE file

It is requirement when packaging for various Linux distributions.

Review documetation

The documentation should be reviewed, and improved as appropriate. Specifically, we should make sure that everything links to the respective man page.

Add `name` field to `inotify_event`

Back when I originally wrote inotify-rs, having a dynamically sized field in a struct was either not possible, or if it was, I didn't know about it. Either way, it's possible today.

From the nomicon:

Structs can actually store a single DST directly as their last field, but this makes them a DST as well

We should look into adding this field to inotify_event. This could possibly make the name handling code in inotify-rs more straight-forward.

Inotify::read_events does not read all events

The documentation for Inotify::read_events says:

Returns any available events

Returns an iterator over all events that are currently available.

However, the function only reads one buffers' worth of data from the inotify file descriptor; if there are more events available than can fit in the buffer, the returned Events iterator returns None without trying to read any more from the file descriptor.

I think this causes the notify crate to delay reporting events. Touching the directory being watched causes the delayed events to be reported.

Add `maintenance` badge to Cargo.toml

See http://doc.crates.io/manifest.html#package-metadata.

Constant definitions not architecture independent

Hi, I have an issue where using the inotify crate, an error is printed during init about invalid value passed to syscall.

I am using mips little endian, and looking at inotify.h i see:
/* Get the platform-dependent flags. */
#include <bits/inotify.h>

I have verified that my correct flags for mips little endian are:
const IN_CLOEXEC : i32 = 0o02000000;
const IN_NONBLOCK : i32 = 0o00000200;

which differ from those in this crate. Would it be possible to pull in architecture independant values for these, maybe from the nix crate?

Br,
Karl

Crate uses deny(warnings), and thus breaks with new Rust versions

This crate does not compile with current versions of Rust, since it uses #[deny(warnings)]. Since Cargo builds dependencies with special flags to prevent this from breaking builds, it's not affecting this crate's users, but it does throw a spanner in the works if you try to build with a local checkout.

There's a case to be made that using #[deny(warnings)] is not a great idea:
https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deny-warnings.md

By disallowing the compiler to build with warnings, a crate author opts out of Rust's famed stability. Sometimes new features or old misfeatures need a change in how things are done, thus lints are written that warn for a certain grace period before being turned to deny.

Here's cuviper making a similar case: https://www.reddit.com/r/rust/comments/f5xpib/psa_denywarnings_is_actively_harmful/

Some crates like to use #![deny(warnings)] or #![cfg_attr(test, deny(warnings)] as a way of enforcing clean code. This is a lot like GCC's -Werror option, and a quick search can show a lot of reasons why that is harmful. It may be OK while you're actively maintaining your code, but once you're not paying attention, small signs of bit-rot like using deprecated APIs will turn into outright errors.

When used as a crate dependency, Cargo will mask this with --cap-lints allow/warn, so it's usually not the end of the world. However, when the Rust teams want to test the impact of a potentially breaking change, they run mass builds with Crater. If your crate is already failing due to deny(warnings), then any future changes that really do break you won't be seen as a regression.