-
Notifications
You must be signed in to change notification settings - Fork 12
Consolidation integration: CI repairs for gpu-only builds, checksum guard, and dogfood lane #173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
047feb9
fix(ci): repair gpu-only builds, checksum guard, and dogfood lane
santhreal 4f87911
fix(sources): the outer docker image archive no longer consumes the u…
santhreal 8ac8fe3
chore(scanner): drop trailing blank line left by probe cleanup
santhreal bcf923d
fix(sources): charge container metadata, not blob payloads, against t…
santhreal 94de1e2
fix(core,cli): lockdown tolerates installed execution packs; pack sta…
santhreal b4d3999
fix(cli): the Excluded coverage gap names git-staged keyhogignore mat…
santhreal 7fd93fe
fix(sources): validate pass mirrors the layer-payload budget exemption
santhreal fbaa97f
fix(cli): open the staging directory with write access for the fsync
santhreal 655ec9d
ci: raise the action-contract timeout to 75 minutes
santhreal c53136e
ci: raise the Integration (CLI) timeout to 105 minutes
santhreal 7ab1466
test(cli): run the row 135 invalidation calibrations on the bounded l…
santhreal 4d95d52
test(ci): bound daemon admission and isolate allocator measurements
santhreal ac50676
test(cli): wire empty-dir e2e and hermetic daemon lifecycle routes
santhreal 4f80916
test(cli): empty-directory scans assert fail-closed coverage semantics
santhreal 0ba1ac5
test(cli): restored suites pin the shipped schema and coverage contract
santhreal 787dc37
test(scanner,cli): nightly lanes pin current contracts
santhreal dce6f70
test(cli): Row 130 install suites use the bounded calibration fixture
santhreal b812369
fix(cli): watcher .keyhog.toml reload + .cargo parity; orphan suite c…
santhreal File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
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
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
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
This file was deleted.
Oops, something went wrong.
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| //! E2E: an empty directory provides no coverage and fails closed. | ||
|
|
||
| use crate::e2e::support::scan_path; | ||
| use keyhog::exit_codes::EXIT_SOURCE_FAILED; | ||
| use tempfile::TempDir; | ||
|
|
||
| /// WHY: zero-byte input cannot prove that a target is clean. Empty, | ||
| /// fully-excluded, and wrong-target scans must not report success. | ||
| #[test] | ||
| fn scan_empty_dir_fails_closed() { | ||
| let dir = TempDir::new().expect("tempdir"); | ||
| let output = scan_path(dir.path(), &[]); | ||
| assert_eq!( | ||
| output.status.code(), | ||
| Some(EXIT_SOURCE_FAILED as i32), | ||
| "empty dir must fail closed; stderr={}", | ||
| String::from_utf8_lossy(&output.stderr) | ||
| ); | ||
| let stderr = String::from_utf8_lossy(&output.stderr); | ||
| assert!( | ||
| stderr.contains("ZERO bytes") && stderr.contains("Nothing was examined"), | ||
| "empty-dir failure must state the missing coverage and corrective context: {stderr}" | ||
| ); | ||
| } |
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🩺 Stability & Availability | 🔴 Critical | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: santhreal/keyhog
Length of output: 453
🏁 Script executed:
Repository: santhreal/keyhog
Length of output: 17426
🌐 Web query:
Microsoft FlushFileBuffers GENERIC_WRITE access directory handle FILE_FLAG_BACKUP_SEMANTICS Rust File sync_all Windows💡 Result:
On Windows, the FlushFileBuffers function is designed to flush buffered data for a specified file or volume [1][2]. Official Microsoft documentation does not include directory handles in the list of valid handles for FlushFileBuffers [1][3], and attempting to use it on a directory handle typically fails [4][5]. Key Technical Points: 1. Handle Compatibility: While you can open a directory handle using the FILE_FLAG_BACKUP_SEMANTICS flag in CreateFile [6][3], this handle is intended for specific operations like BackupRead, BackupWrite, and retrieving metadata [3]. It is not a supported target for flushing operations via FlushFileBuffers [4][5]. 2. FlushFileBuffers Requirements: This function requires a handle opened with GENERIC_WRITE access [1]. Even if a directory handle is opened with GENERIC_WRITE, calling FlushFileBuffers on it is not guaranteed to work and often results in errors such as ERROR_INVALID_HANDLE or invalid device requests depending on the file system and drive type [1][4]. 3. Rust File::sync_all: In Rust's standard library, the sync_all method on a File object is implemented to sync file content and metadata to disk [7][8]. Because FlushFileBuffers is not a viable mechanism for syncing directory contents on Windows, Rust's std::fs implementation does not (and cannot) perform directory-level syncing via this function [9]. If you need to ensure the durability of file operations (such as renames or creations) within a directory on Windows, simply flushing the directory handle is generally not effective [10][4]. For developers, if your goal is to ensure the durability of file system changes, note that Windows handles file system metadata durability differently than POSIX-based systems [4]. You generally need to ensure the file itself is flushed or opened with FILE_FLAG_WRITE_THROUGH [2][10]. There is no standard, reliable system call to "fsync" a directory on Windows to guarantee the persistence of directory entry changes [4][5].
Citations:
🌐 Web query:
site:learn.microsoft.com FlushFileBuffers directory handle ERROR_INVALID_HANDLE GENERIC_WRITE💡 Result:
The FlushFileBuffers function is designed to flush the internal buffers of a file, communication device, or named pipe to the physical medium [1][2]. The function explicitly requires a handle that has been opened with the GENERIC_WRITE access right [1]. While a directory handle can be obtained using CreateFile with the FILE_FLAG_BACKUP_SEMANTICS flag [3], FlushFileBuffers is generally not intended for use with directory handles. When FlushFileBuffers is called on a handle that does not support the operation—such as a console output handle or other handle types where flushing is not defined or applicable—the function returns FALSE and GetLastError typically returns ERROR_INVALID_HANDLE [1]. If you are attempting to ensure that file system metadata changes (such as file creation, renaming, or timestamp updates) are committed to disk, FlushFileBuffers should be called on the specific file handle rather than the directory handle [1][4]. Alternatively, if you need to avoid the performance overhead of manual flushes, you can open files with the FILE_FLAG_WRITE_THROUGH flag, which requests that the system write through any intermediate cache to the disk [5][4].
Citations:
🌐 Web query:
site:github.com/rust-lang/rust library/std/src/sys/fs/windows.rs sync_all FlushFileBuffers💡 Result:
In the Rust standard library's Windows implementation, located at library/std/src/sys/fs/windows.rs (or the corresponding location in the current repository structure), the sync_all method is implemented by calling the Windows API function FlushFileBuffers [1][2][3][4]. The implementation is defined as follows: pub fn fsync(&self) -> io::Result<> { cvt(unsafe { c::FlushFileBuffers(self.handle.as_raw_handle) })?; Ok() } pub fn datasync(&self) -> io::Result<> { self.fsync } Key details include: 1. Relationship to Sync: The sync_all method maps directly to fsync, which invokes the Win32 FlushFileBuffers function [1][4]. As seen in the source code, datasync is also implemented by calling the same fsync method [1][4]. 2. FlushFileBuffers: This is a Windows API function that flushes the buffers of a specified file handle to disk, ensuring that all buffered data is written to the physical storage device [5]. 3. Rust's File::flush: It is important to distinguish this from the standard library's File::flush method, which is a no-op (it does nothing) on both Windows and Unix platforms for file types because file handles do not have internal user-space buffers [1][4][6]. The synchronization of data to disk is instead handled by explicit methods like sync_all [6].
Citations:
🏁 Script executed:
Repository: santhreal/keyhog
Length of output: 17357
🌐 Web query:
Windows NTFS FlushFileBuffers directory handle GENERIC_READ GENERIC_WRITE FILE_FLAG_BACKUP_SEMANTICS works💡 Result:
Using FlushFileBuffers on a directory handle, even when opened with FILE_FLAG_BACKUP_SEMANTICS, is not supported and does not provide a reliable way to flush directory metadata to disk on Windows [1][2]. While you can successfully obtain a handle to a directory by using CreateFile with the FILE_FLAG_BACKUP_SEMANTICS flag [3][4], passing that handle to FlushFileBuffers generally fails [1]. Official documentation for FlushFileBuffers specifies that it operates on handles to files, communications devices, or the server end of named pipes [5]. Although some users have observed that it may sometimes succeed or appear to flush on specific file systems (such as FAT) as a side effect of how the underlying driver behaves, this is not a documented or guaranteed behavior for NTFS or other modern Windows file systems [6]. On Windows, there is no direct equivalent to the POSIX fsync on a directory handle [1][2]. If you require durability for file system operations, you should: 1. Use FlushFileBuffers on the handle of the specific file you have modified [5][7]. 2. If you need to ensure an entire volume is flushed, FlushFileBuffers can be called on a volume handle, though this requires administrator privileges [6][2]. 3. For kernel-mode operations, the Windows Driver Kit (WDK) provides functions like NtFlushBuffersFileEx, which offer more granular control over flushing file data and metadata, but these are intended for driver development and not standard user-mode applications [8]. In summary, attempting to use FlushFileBuffers on a directory handle is not a standard or reliable practice for ensuring data integrity on NTFS [1][2].
Citations:
🌐 Web query:
site:github.com directory FlushFileBuffers FILE_FLAG_BACKUP_SEMANTICS GENERIC_WRITE Windows💡 Result:
On Windows, calling FlushFileBuffers on a handle to a directory is not a supported or reliable way to synchronize directory metadata to disk [1][2][3]. To obtain a handle to a directory, you must call CreateFile with the FILE_FLAG_BACKUP_SEMANTICS flag [4][5]. While it is technically possible to pass a directory handle opened with GENERIC_WRITE access to FlushFileBuffers without the function returning an error, this does not perform a synchronization of the directory's contents or metadata in the way that the POSIX fsync on a directory does on other operating systems [6][2][3]. Key technical observations: 1. Requirement for Handle Access: If you attempt to call FlushFileBuffers on a directory handle that was opened with only GENERIC_READ access, the call will fail with ERROR_ACCESS_DENIED [6]. It requires GENERIC_WRITE access to succeed [6]. 2. Lack of Equivalent Functionality: Unlike POSIX-compliant systems where fsync on a directory can flush directory entries to disk, Windows lacks a direct equivalent API for flushing directory-specific metadata or entry changes [1][2][3]. 3. Recommended Alternatives: Developers encountering this issue in cross-platform applications are generally advised to skip directory synchronization on Windows or to ensure individual files are handled correctly using FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH when creating or opening them, rather than relying on flushing a directory handle [1][7][6]. 4. Volume-Level Flushing: For applications requiring true volume-wide synchronization, FlushFileBuffers can be used on a volume handle (e.g., \.\C:), but this requires administrative privileges [8][3].
Citations:
🌐 Web query:
site:learn.microsoft.com "FlushFileBuffers" "directory" handle💡 Result:
The FlushFileBuffers function is designed to flush the internal buffers of a specified file, communication device, or pipe to the underlying storage or device [1][2]. Its primary purpose is to ensure that buffered data is written out to disk or the target destination. While you can obtain a handle to a directory by opening it with the FILE_FLAG_BACKUP_SEMANTICS flag [3], the FlushFileBuffers function is not intended for use with directory handles. When called on a handle, the function expects a file handle that supports write access (specifically requiring the GENERIC_WRITE access right) [1]. Using it with a handle to a directory typically does not provide the intended functionality of flushing file system metadata or directory contents to disk. For managing metadata or ensuring changes are committed to disk for directories and files, Windows generally relies on other mechanisms, such as: 1. System-level caching and write-through operations: Using flags like FILE_FLAG_WRITE_THROUGH when opening files can ensure that both data and metadata (such as timestamps or renames) are flushed to persistent media [4][5][6]. 2. File system operations: File system changes are managed by the operating system's cache manager and file system drivers (like NTFS), which handle the consistency of directory structures independently of FlushFileBuffers [4][2]. If you attempt to use FlushFileBuffers on a handle that is not a file, pipe, or communication device, the function will likely fail, returning zero, and you can retrieve the specific error code via GetLastError [1].
Citations:
Do not call
sync_all()on directory handles on Windows.sync_all()maps toFlushFileBuffers, which requiresGENERIC_WRITE, but Windows does not reliably support flushing directory handles. Adding.write(true)only passes the access check and does not make directory synchronization valid. Skip this operation on Windows or use a documented durability mechanism.🤖 Prompt for AI Agents
Source: MCP tools