Fix packaging asset paths and legacy binaries#1898
Merged
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
114
to
+118
| assets = [ | ||
| ["target/@TARGET@/@PROFILE@/oc-rsync", "usr/bin/oc-rsync", "755"], | ||
| ["target/@TARGET@/@PROFILE@/oc-rsyncd", "usr/bin/oc-rsyncd", "755"], | ||
| ["target/@TARGET@/@PROFILE@/rsync", "usr/libexec/oc-rsync/rsync", "755"], | ||
| ["target/@TARGET@/@PROFILE@/rsyncd", "usr/libexec/oc-rsync/rsyncd", "755"], | ||
| ["target/release/oc-rsync", "usr/bin/oc-rsync", "755"], | ||
| ["target/release/oc-rsyncd", "usr/bin/oc-rsyncd", "755"], | ||
| ["target/release/rsync", "usr/libexec/oc-rsync/rsync", "755"], | ||
| ["target/release/rsyncd", "usr/libexec/oc-rsync/rsyncd", "755"], |
There was a problem hiding this comment.
The asset lists now hard-code binaries under target/release/..., but the packaging commands use the dist profile by default (cargo xtask package passes --profile dist and [package.metadata.rpm.cargo] sets profile = "dist"). Those builds emit artifacts in target/dist, so cargo deb/cargo rpm build will fail to copy oc-rsync* because the referenced target/release paths do not exist. Point the assets at the profile-dependent directory (e.g. target/@PROFILE@/...) so the paths match the binaries that are actually built.
Useful? React with 👍 / 👎.
7 tasks
oferchen
added a commit
that referenced
this pull request
May 1, 2026
Add CompletionPump: a shared completion-port driver that owns a worker thread looping on GetQueuedCompletionStatusEx and dispatches each completion entry to a per-operation handler keyed by the OVERLAPPED pointer. This is the Windows analogue of an io_uring CQE drain and is the foundational building block for the upcoming batched-write API (#1898), the concurrent file/socket paths (#1928-#1932), and the IOCP benchmark harness (#1899). Existing IocpReader/IocpWriter create a private port and inline-call GetQueuedCompletionStatus per operation, so the pump introduces a process-wide proactor without disturbing those single-op paths. Cross-platform: real implementation lives behind #[cfg(all(target_os = "windows", feature = "iocp"))]; non-Windows targets get an Unsupported-returning stub so the crate still compiles on Linux and macOS. All unsafe stays inside fast_io per the workspace unsafe-code policy.
4 tasks
oferchen
added a commit
that referenced
this pull request
May 4, 2026
…1898) (#3609) * feat(fast_io): add IocpDiskBatch matching IoUringDiskBatch surface (#1898) Adds a Windows IOCP batched-write API that mirrors the IoUringDiskBatch public surface, so the disk-commit thread can batch overlapped WriteFile submissions through a completion port and drain them with GetQueuedCompletionStatusEx. The new IocpDiskBatch: - begin_file / write_data / flush / commit_file / bytes_written - Reopens the file with FILE_FLAG_OVERLAPPED via ReOpenFile and associates it with a private completion port. - Tracks in-flight overlapped operations as Pin<Box<OverlappedOp>> so pointers passed to WriteFile remain stable until completion, and matches each completion to its op by OVERLAPPED address. - Best-effort flush on Drop to avoid leaking pending I/O. - Stub on non-Windows / when the iocp feature is off so cross-platform builds keep compiling. Wires through disk-commit: - DiskCommitConfig gains iocp_policy: fast_io::IocpPolicy (default Auto) - Writer enum gains an Iocp variant (Windows + iocp feature only) - process_file / process_whole_file accept an iocp_batch parameter and select it in make_writer when sparse mode is off and append_offset is zero. - The disk thread constructs a single IocpDiskBatch up-front (only when io_uring is unavailable so the two backends stay mutually exclusive) and threads it into every per-file call. Tests cover policy plumbing, Windows batched submission of N writes, completion ordering independent of submission order, error propagation from a failed reopen, large writes that exceed the buffer, fsync via FlushFileBuffers, drop semantics, and many rotations to verify no leaked overlapped handles. * style: cargo fmt --all * fix(transfer): add iocp feature forwarding to fast_io/iocp The transfer crate uses #[cfg(feature = "iocp")] in disk_commit/{process,writer}.rs without declaring `iocp` as a feature in its own Cargo.toml. Under RUSTFLAGS=-D warnings this triggers `unexpected_cfgs` as a hard clippy error, breaking CI on the feat/iocp-disk-batch branch. Add `iocp = ["fast_io/iocp"]` to the transfer crate features (mirroring the io_uring pattern), and forward `transfer/iocp` from the workspace top-level iocp feature so a single `--features iocp` activates both crates.
oferchen
added a commit
that referenced
this pull request
May 5, 2026
Add CompletionPump: a shared completion-port driver that owns a worker thread looping on GetQueuedCompletionStatusEx and dispatches each completion entry to a per-operation handler keyed by the OVERLAPPED pointer. This is the Windows analogue of an io_uring CQE drain and is the foundational building block for the upcoming batched-write API (#1898), the concurrent file/socket paths (#1928-#1932), and the IOCP benchmark harness (#1899). Existing IocpReader/IocpWriter create a private port and inline-call GetQueuedCompletionStatus per operation, so the pump introduces a process-wide proactor without disturbing those single-op paths. Cross-platform: real implementation lives behind #[cfg(all(target_os = "windows", feature = "iocp"))]; non-Windows targets get an Unsupported-returning stub so the crate still compiles on Linux and macOS. All unsafe stays inside fast_io per the workspace unsafe-code policy.
oferchen
added a commit
that referenced
this pull request
May 5, 2026
…1898) (#3609) * feat(fast_io): add IocpDiskBatch matching IoUringDiskBatch surface (#1898) Adds a Windows IOCP batched-write API that mirrors the IoUringDiskBatch public surface, so the disk-commit thread can batch overlapped WriteFile submissions through a completion port and drain them with GetQueuedCompletionStatusEx. The new IocpDiskBatch: - begin_file / write_data / flush / commit_file / bytes_written - Reopens the file with FILE_FLAG_OVERLAPPED via ReOpenFile and associates it with a private completion port. - Tracks in-flight overlapped operations as Pin<Box<OverlappedOp>> so pointers passed to WriteFile remain stable until completion, and matches each completion to its op by OVERLAPPED address. - Best-effort flush on Drop to avoid leaking pending I/O. - Stub on non-Windows / when the iocp feature is off so cross-platform builds keep compiling. Wires through disk-commit: - DiskCommitConfig gains iocp_policy: fast_io::IocpPolicy (default Auto) - Writer enum gains an Iocp variant (Windows + iocp feature only) - process_file / process_whole_file accept an iocp_batch parameter and select it in make_writer when sparse mode is off and append_offset is zero. - The disk thread constructs a single IocpDiskBatch up-front (only when io_uring is unavailable so the two backends stay mutually exclusive) and threads it into every per-file call. Tests cover policy plumbing, Windows batched submission of N writes, completion ordering independent of submission order, error propagation from a failed reopen, large writes that exceed the buffer, fsync via FlushFileBuffers, drop semantics, and many rotations to verify no leaked overlapped handles. * style: cargo fmt --all * fix(transfer): add iocp feature forwarding to fast_io/iocp The transfer crate uses #[cfg(feature = "iocp")] in disk_commit/{process,writer}.rs without declaring `iocp` as a feature in its own Cargo.toml. Under RUSTFLAGS=-D warnings this triggers `unexpected_cfgs` as a hard clippy error, breaking CI on the feat/iocp-disk-batch branch. Add `iocp = ["fast_io/iocp"]` to the transfer crate features (mirroring the io_uring pattern), and forward `transfer/iocp` from the workspace top-level iocp feature so a single `--features iocp` activates both crates.
This was referenced May 5, 2026
4 tasks
oferchen
added a commit
that referenced
this pull request
May 18, 2026
…1898) (#3609) * feat(fast_io): add IocpDiskBatch matching IoUringDiskBatch surface (#1898) Adds a Windows IOCP batched-write API that mirrors the IoUringDiskBatch public surface, so the disk-commit thread can batch overlapped WriteFile submissions through a completion port and drain them with GetQueuedCompletionStatusEx. The new IocpDiskBatch: - begin_file / write_data / flush / commit_file / bytes_written - Reopens the file with FILE_FLAG_OVERLAPPED via ReOpenFile and associates it with a private completion port. - Tracks in-flight overlapped operations as Pin<Box<OverlappedOp>> so pointers passed to WriteFile remain stable until completion, and matches each completion to its op by OVERLAPPED address. - Best-effort flush on Drop to avoid leaking pending I/O. - Stub on non-Windows / when the iocp feature is off so cross-platform builds keep compiling. Wires through disk-commit: - DiskCommitConfig gains iocp_policy: fast_io::IocpPolicy (default Auto) - Writer enum gains an Iocp variant (Windows + iocp feature only) - process_file / process_whole_file accept an iocp_batch parameter and select it in make_writer when sparse mode is off and append_offset is zero. - The disk thread constructs a single IocpDiskBatch up-front (only when io_uring is unavailable so the two backends stay mutually exclusive) and threads it into every per-file call. Tests cover policy plumbing, Windows batched submission of N writes, completion ordering independent of submission order, error propagation from a failed reopen, large writes that exceed the buffer, fsync via FlushFileBuffers, drop semantics, and many rotations to verify no leaked overlapped handles. * style: cargo fmt --all * fix(transfer): add iocp feature forwarding to fast_io/iocp The transfer crate uses #[cfg(feature = "iocp")] in disk_commit/{process,writer}.rs without declaring `iocp` as a feature in its own Cargo.toml. Under RUSTFLAGS=-D warnings this triggers `unexpected_cfgs` as a hard clippy error, breaking CI on the feat/iocp-disk-batch branch. Add `iocp = ["fast_io/iocp"]` to the transfer crate features (mirroring the io_uring pattern), and forward `transfer/iocp` from the workspace top-level iocp feature so a single `--features iocp` activates both crates.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_6907a36a00208323b9241c6b0eefd330