Repository navigation
fix(windows): dehydrate and measure connected Cloud Files placeholders - #518
Conversation
A connected file placeholder is a cloud reparse point that Java NIO does not report as a regular file, so allocatedBytes and dehydrate returned 0 for every hydrated placeholder. Free up space, automatic cleanup, and the storage summary therefore found nothing to free. Classify the path from native find data with the startup enumeration rule and dehydrate only an unpinned, in-sync file placeholder. Windows refusals for content that became dirty, pinned, or open elsewhere free nothing instead of failing the whole pass, and freed totals count the bytes each dehydration released. Dehydration opens the file for attribute access only, so a reader that denies write sharing is reported as in use rather than as a sharing violation. Native tests on a disposable sync root hydrate, free, and reopen a file, and keep dirty, pinned, and externally open files local.
…k-commit' into fix/windows-cloud-files-dehydrate-classification
Obiente previewNC Native · Obiente updates this comment as the preview changes. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 77fe6f6c1e
ℹ️ 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".
A Windows CI runner reported no allocated bytes for a placeholder right after its content was read, although the same sample was complete locally. Wait within a bound until the file reports its whole size as allocated, and report the raw allocation result and placeholder state on timeout. Shorten the changelog summary to the fragment limit.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cb747b1611
ℹ️ 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".
CfDehydratePlaceholder requires an exclusive handle, so dehydration now holds an exclusive CfOpenFileWithOplock handle. An oplock that cannot be taken or breaks first keeps the content local and frees nothing. An online-only placeholder allocates no bytes and is skipped before any native call, so a cleanup pass does not scale with the remote tree. Automatic cleanup executes its plan through one checker that also keeps a file whose known revision changed after planning, besides the existing pin, sync state, and allocated size checks.
…k-commit' into fix/windows-cloud-files-dehydrate-classification # Conflicts: # tools/kotlin-file-size-baseline.txt
0b529e3
into
fix/windows-cloud-files-writeback-commit
Stacked on #517 (base
fix/windows-cloud-files-writeback-commit).Outcome
On Windows, Free up space, automatic cleanup, and the Virtual files storage summary now work on downloaded files. Before this change they reported nothing to free while the provider was connected.
While the provider is connected, every file placeholder is a reparse point with an
IO_REPARSE_TAG_CLOUD*tag, and Java NIO does not report it as a regular file.JnaWindowsCloudFilesApi.allocatedBytesanddehydrateboth returned 0 early whenFiles.isRegularFilewas false. On a disposable sync root, a hydrated, in-sync 256 KiB placeholder allocated 262144 bytes, yet the API reported 0 anddehydratedid nothing.Changes
allocatedBytesanddehydrateclassify the path from native find data, using the same rule as the startup enumeration (windowsCloudLocalEntry).dehydrateacts only on an unpinned, in-sync file placeholder (WindowsCloudDehydration.kt) and returns the bytes it actually released.CfDehydratePlaceholdercontract requires, dehydration holds an exclusiveCfOpenFileWithOplockhandle.0x80070020) or breaks first, or Windows refuses a file that became dirty (0x80070179), pinned (0x80070188), or open in another application (0x80070187).dehydratePlannedEvictions. It keeps a file whose known revision, pin, sync state, or allocated size changed after planning.freeUpSpaceand automatic cleanup add up whatdehydratereturns, so a refused file is not counted as freed.WindowsCloudExternalProcess.kt.WindowsCloudFilesJna.kt(1030 to 1023) andWindowsCloudFilesProvider.kt(2331 to 2319, measured after merging the base).docs/windows-release.mdgains a dehydration and storage accounting section, and this PR adds a changelog fragment.Validation
WindowsCloudFilesDehydrationTesthas 3 deterministic tests and 3 native Windows tests on a disposable sync root with a synthetic backend. The deterministic tests cover classification, refusal codes, and planned evictions that changed after planning. The native tests are:./gradlew :ui:desktopTestpassed on Windows 11 with JDK 21: 3995 tests, 0 failures, 69 skipped (before the review fixes). After the review fixes and the base merge,--tests '*WindowsCloud*'passed: 147 tests, 2 skipped.bash tools/check-kotlin-architecture.shpasses.bash tools/check-repository.shpasses.Limits
PHCM_DISGUISE_PLACEHOLDERmode; the packaged launcher's mode has not been measured.