Handle cargo-rpm absence before profile validation#1866
Merged
Conversation
2 tasks
oferchen
added a commit
that referenced
this pull request
Apr 28, 2026
Documents the actual Windows feature state so users have realistic expectations: ACLs (-A), xattrs (-X), symlinks, devices, and ownership are stubbed on Windows, while permissions degrade to the read-only flag and IOCP is implemented in fast_io but not yet wired into the transfer pipeline. References tasks #1866 (Windows ACLs), #1867 (Windows xattrs), and #1868 (IOCP wiring).
4 tasks
oferchen
added a commit
that referenced
this pull request
May 1, 2026
Documents the actual Windows feature state so users have realistic expectations: ACLs (-A), xattrs (-X), symlinks, devices, and ownership are stubbed on Windows, while permissions degrade to the read-only flag and IOCP is implemented in fast_io but not yet wired into the transfer pipeline. References tasks #1866 (Windows ACLs), #1867 (Windows xattrs), and #1868 (IOCP wiring).
This was referenced May 1, 2026
oferchen
added a commit
that referenced
this pull request
May 1, 2026
Adds the windows crate to the metadata Cargo.lock entry to match the target-gated dependency added in the parent commit. Without this, cargo --locked (used by MSRV and fmt+clippy CI checks) fails with "the lock file needs to be updated but --locked was passed".
oferchen
added a commit
that referenced
this pull request
May 1, 2026
…yInfo (#1866) Adds a real Windows ACL apply path that uses Win32 GetNamedSecurityInfoW/SetNamedSecurityInfoW so --acls/-A preserves NTFS discretionary ACLs in cross-platform transfers. Replaces the prior no-op stub which only emitted a warning on Windows. The new module reads/writes DACL_SECURITY_INFORMATION only (SACL is deliberately left as follow-up to avoid SE_SECURITY_NAME privilege requirements). SID/uid mapping follows upstream's lossy cross-platform convention: senders encode the resolved account name and use the SID's lower sub-authority (RID) as the synthetic uid/gid; receivers look up the SID by account name and drop ACEs that cannot be mapped, mirroring acls.c:902-928. Wires into the existing acl module dispatch via lib.rs cfg gating so non-Windows builds remain unchanged.
oferchen
added a commit
that referenced
this pull request
May 1, 2026
Adds the windows crate to the metadata Cargo.lock entry to match the target-gated dependency added in the parent commit. Without this, cargo --locked (used by MSRV and fmt+clippy CI checks) fails with "the lock file needs to be updated but --locked was passed".
6 tasks
oferchen
added a commit
that referenced
this pull request
May 1, 2026
) windows-rs 0.62.2 exports ACCESS_ALLOWED_ACE_TYPE (the ACE-type discriminant byte, value 0x0) under windows::Win32::System::SystemServices, not under windows::Win32::Security where ACCESS_ALLOWED_ACE (the struct) lives. The original import in #1866 placed both names in the Security group, which fails to resolve and breaks every Windows CI job on master. upstream: WinNT.h
6 tasks
oferchen
added a commit
that referenced
this pull request
May 2, 2026
…-feature fix(metadata): add Win32_System_SystemServices feature for ACL build (#1866)
4 tasks
oferchen
added a commit
that referenced
this pull request
May 2, 2026
#3558) * feat(metadata): wire Windows ACL support through engine pipeline (#1866) The Windows ACL implementation in `metadata::acl_windows` was previously unreachable because every engine and CLI call site gated invocation on `cfg(all(unix, feature = "acl"))`. This widens the gates to `cfg(all(any(unix, windows), feature = "acl"))` so `--acls`/`-A` now flows through to the Win32 `GetNamedSecurityInfoW` / `SetNamedSecurityInfoW` paths on Windows. Scope: - engine local_copy executor (file, special, directory recursion) - engine `sync_acls_if_requested` and metadata-sync helpers - engine `LocalCopyOptions` setters / accessors / builder validation - core client config builder, run, remote invocation, flags - cli drive workflow, preflight feature validation, drive config - transfer flag emission Tests/fixtures that drive raw libacl / exacl FFI directly remain unix-only intentionally; only dispatch through `metadata::sync_acls` gains the Windows code path. Refs #1866 * fix(engine): widen mode parameter cfg for windows+acl path The mode parameter and LocalCopyExecution import in apply_final_directory_metadata were gated on `all(unix, any(feature = "acl", feature = "xattr"))`, but the call site for sync_acls_if_requested is gated on `all(any(unix, windows), feature = "acl")`. When building on Windows with the acl feature enabled (without xattr), `mode` was not in scope, causing E0425 in CI. Widen both gates to also include `all(windows, feature = "acl")` so the Windows + acl combination compiles. * fix(engine): widen call-site cfg for windows+acl mode arg The callee apply_final_directory_metadata accepts `mode` under `any(unix+acl|xattr, windows+acl)` but the caller was passing it under the narrower `unix+acl|xattr` gate. On windows+acl the call passed 5 args instead of 6, causing E0061. Match the caller's gate to the callee's.
4 tasks
oferchen
added a commit
that referenced
this pull request
May 5, 2026
Documents the actual Windows feature state so users have realistic expectations: ACLs (-A), xattrs (-X), symlinks, devices, and ownership are stubbed on Windows, while permissions degrade to the read-only flag and IOCP is implemented in fast_io but not yet wired into the transfer pipeline. References tasks #1866 (Windows ACLs), #1867 (Windows xattrs), and #1868 (IOCP wiring).
oferchen
added a commit
that referenced
this pull request
May 5, 2026
…yInfo (#1866) Adds a real Windows ACL apply path that uses Win32 GetNamedSecurityInfoW/SetNamedSecurityInfoW so --acls/-A preserves NTFS discretionary ACLs in cross-platform transfers. Replaces the prior no-op stub which only emitted a warning on Windows. The new module reads/writes DACL_SECURITY_INFORMATION only (SACL is deliberately left as follow-up to avoid SE_SECURITY_NAME privilege requirements). SID/uid mapping follows upstream's lossy cross-platform convention: senders encode the resolved account name and use the SID's lower sub-authority (RID) as the synthetic uid/gid; receivers look up the SID by account name and drop ACEs that cannot be mapped, mirroring acls.c:902-928. Wires into the existing acl module dispatch via lib.rs cfg gating so non-Windows builds remain unchanged.
oferchen
added a commit
that referenced
this pull request
May 5, 2026
Adds the windows crate to the metadata Cargo.lock entry to match the target-gated dependency added in the parent commit. Without this, cargo --locked (used by MSRV and fmt+clippy CI checks) fails with "the lock file needs to be updated but --locked was passed".
oferchen
added a commit
that referenced
this pull request
May 5, 2026
) windows-rs 0.62.2 exports ACCESS_ALLOWED_ACE_TYPE (the ACE-type discriminant byte, value 0x0) under windows::Win32::System::SystemServices, not under windows::Win32::Security where ACCESS_ALLOWED_ACE (the struct) lives. The original import in #1866 placed both names in the Security group, which fails to resolve and breaks every Windows CI job on master. upstream: WinNT.h
oferchen
added a commit
that referenced
this pull request
May 5, 2026
…1866) PR #3544 moved the ACCESS_ALLOWED_ACE_TYPE import to windows::Win32::System::SystemServices to match windows-rs 0.62, but did not add the corresponding Cargo feature to Cargo.toml. This left the import unresolved on Windows targets: error[E0432]: unresolved import `windows::Win32::System::SystemServices` --> crates/metadata/src/acl_windows.rs:67:30 | 67 | use windows::Win32::System::SystemServices::ACCESS_ALLOWED_ACE_TYPE; | ^^^^^^^^^^^^^^ could not find `SystemServices` in `System` | = note: the item is gated behind the `Win32_System_SystemServices` feature Add the missing feature to the windows-rs dependency declaration so the ACL code compiles on all Windows toolchains (stable/beta/nightly/GNU). Unblocks: master CI (Windows stable required check), all 11 open PRs.
oferchen
added a commit
that referenced
this pull request
May 5, 2026
…-feature fix(metadata): add Win32_System_SystemServices feature for ACL build (#1866)
oferchen
added a commit
that referenced
this pull request
May 5, 2026
#3558) * feat(metadata): wire Windows ACL support through engine pipeline (#1866) The Windows ACL implementation in `metadata::acl_windows` was previously unreachable because every engine and CLI call site gated invocation on `cfg(all(unix, feature = "acl"))`. This widens the gates to `cfg(all(any(unix, windows), feature = "acl"))` so `--acls`/`-A` now flows through to the Win32 `GetNamedSecurityInfoW` / `SetNamedSecurityInfoW` paths on Windows. Scope: - engine local_copy executor (file, special, directory recursion) - engine `sync_acls_if_requested` and metadata-sync helpers - engine `LocalCopyOptions` setters / accessors / builder validation - core client config builder, run, remote invocation, flags - cli drive workflow, preflight feature validation, drive config - transfer flag emission Tests/fixtures that drive raw libacl / exacl FFI directly remain unix-only intentionally; only dispatch through `metadata::sync_acls` gains the Windows code path. Refs #1866 * fix(engine): widen mode parameter cfg for windows+acl path The mode parameter and LocalCopyExecution import in apply_final_directory_metadata were gated on `all(unix, any(feature = "acl", feature = "xattr"))`, but the call site for sync_acls_if_requested is gated on `all(any(unix, windows), feature = "acl")`. When building on Windows with the acl feature enabled (without xattr), `mode` was not in scope, causing E0425 in CI. Widen both gates to also include `all(windows, feature = "acl")` so the Windows + acl combination compiles. * fix(engine): widen call-site cfg for windows+acl mode arg The callee apply_final_directory_metadata accepts `mode` under `any(unix+acl|xattr, windows+acl)` but the caller was passing it under the narrower `unix+acl|xattr` gate. On windows+acl the call passed 5 args instead of 6, causing E0061. Match the caller's gate to the callee's.
This was referenced May 5, 2026
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_6905e39d75c4832395d706dc69384016