Unable to Build Project on Windows due to Unix-specific Dependencies

[manuelinfosec]

I encountered an error while attempting to build the project on my Windows machine. The error message indicates that the import tokio::signal::unix::Signal is unresolved, suggesting that the project is relying on Unix-specific dependencies that are not compatible with Windows.

Error message:

error[E0432]: unresolved import `tokio::signal::unix`
 --> crates\tripwire\src\signalstream.rs:6:20
  |
6 | use tokio::signal::unix::Signal;
  |                    ^^^^ could not find `unix` in `signal`

error[E0432]: unresolved import `tokio::signal::unix`
 --> crates\tripwire\src\tripwire.rs:9:13
  |
9 |     signal::unix::{signal, SignalKind},
  |             ^^^^ could not find `unix` in `signal`

For more information about this error, try `rustc --explain E0432`.
error: could not compile `tripwire` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

As I am on a Windows machine, I am unable to build the project due to this dependency on Unix-specific functionality.

Proposed Solution

I intend to contribute to the project by extending its codebase to support development on Windows. My plan involves refactoring the following files:

• crates\tripwire\src\signalstream.rs
• crates\tripwire\src\tripwire.rs

To achieve compatibility with Windows, I propose using conditional compilation (#[cfg()] attributes) to introduce different code paths based on the target platform. This approach will allow the project to maintain cross-platform compatibility while accommodating Windows-specific requirements. At least, for maximizing the project's accessibility to contributions from the community to ensure developers without access to Unix-based machines can participate.

I am willing to work on implementing these changes and submitting a pull request. However, I would appreciate guidance and feedback from the maintainers on the best practices for contributing in the project.

Looking forward to contributing to the project and resolving this issue. Thank you for your attention to this matter.

[gedw99]

Windows support would be great

[manuelinfosec]

Major Challenge

In addition to the initial issue regarding Unix-specific dependencies, I have faced another significant challenge. The source code located at crates\sqlite3-restore\src\lib.rs is running very Unix-heavy processes, a scenario that wasn't anticipated when the issue was opened, which appears to be the only hurdle for contribution from Windows machines.

[jeromegn]

We'd be happy to accept a change to support Windows! We didn't have the need to for ourselves and therefore didn't build it.

sqlite3-restore is an optional feature really. It allows restoring a backup "on-line" without restarting apps with connections to the SQLite database. I found that it's not working 100% and would need a once-over from the original creator @benbjohnson (it was translated to Rust to easily embed it in this program).

The rest shouldn't be too hard to adapt.

[manuelinfosec]

We'd be happy to accept a change to support Windows! We didn't have the need to for ourselves and therefore didn't build it.

sqlite3-restore is an optional feature really. It allows restoring a backup "on-line" without restarting apps with connections to the SQLite database. I found that it's not working 100% and would need a once-over from the original creator @benbjohnson (it was translated to Rust to easily embed it in this program).

The rest shouldn't be too hard to adapt.

I handled the Windows signal stream by "disabling" the Unix version (for Windows targets) and switching to a Windows version. Does this mean I can do the same for sqlite-restore too?

[jeromegn]

I handled the Windows signal stream by "disabling" the Unix version (for Windows targets) and switching to a Windows version. Does this mean I can do the same for sqlite-restore too?

Maybe switch the Restore command handler to just copy the DB over the existing one (though that's a scary thing to do, considering the WAL and shared memory file... you'd likely want to add a warning or even a prompt for the user to accept the consequences) and disable the db lock command (which uses sqlite3-restore).