DioxusLabs / DioxusLabs/dioxus
0.7.9/0.7.10: #5504 resource-dir copy fix not included despite PR #5619 merging before 0.7.10 release
- Dominant language
- Rust
- Stars
- 39.1k
- Forks
- 1.9k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 4
Description
**Problem**
`dx bundle --release` fails with `PermissionDenied` when copying directory resources on Windows, in both `dioxus-cli` 0.7.9 (3e43ffa) and 0.7.10 (57d6794) — despite the fix for this exact issue (#5504) having been merged in PR #5619 (commit `6d300fcd6`, merged 2026-07-29T03:06:28Z).
I dug into this because #5504 shows as CLOSED and I assumed 0.7.10 (released 2026-07-30, a day after the merge) would include the fix. It doesn't reproduce the fix — the `PermissionDenied` behavior is identical to what #5504 originally reported.
Git evidence:
- `v0.7.10` tag commit: `57d6794` (committer date 2026-07-30T22:33:31Z)
- Fix commit `6d300fcd6` (PR #5619) is **not an ancestor** of `v0.7.10` — `gh api repos/dioxuslabs/dioxus/compare/6d300fcd6...v0.7.10` reports `status: diverged`, `behind_by: 56`. So the fix landed on `main` but the `0.7.x` release line apparently branches separately and didn't pick it up.
**Steps To Reproduce**
1. `Dioxus.toml`:
```toml
[bundle]
resources = [
"./soundpacks/keyboard",
"./soundpacks/keyboard/cherrymx-black-abs",
"./assets",
]
```
(directories, each containing a mix of files — .ogg/.jpg/.json in my case)
2. `cargo binstall dioxus-cli@0.7.9 --force` (or `@0.7.10`), then `dx bundle --release` on Windows (`windows-latest` GitHub Actions runner reproduces identically — not environment-specific, tested both locally and in clean CI).
Result:
```
ERROR Failed to bundle project: Error {
context: "Failed to copy resource ./soundpacks/keyboard/cherrymx-brown-pbt -> ...\nsis\_staging\cherrymx-brown-pbt",
source: Os { code: 5, kind: PermissionDenied, message: "Access is denied." },
}
```
Also tried glob patterns as a workaround (`"soundpacks/**/*.ogg"`, even single-level `"dir/*"`) per the documented syntax (`resources = ["main.css", "**/*.png"]`) — these silently resolve to nothing (`WARN Resource not found: ...`) rather than erroring, so they're not a viable workaround either. Only fully literal single-file paths (no glob, no directory) copy successfully.
**Confirmed fixed in**: `dioxus-cli@0.8.0-alpha.1` — same `Dioxus.toml` (directories, no changes) bundles successfully, all resources verified present in `_staging/`.
**Expected behavior**
`0.7.9`/`0.7.10` should include the #5504 fix since PR #5619 merged to `main` before the 0.7.10 release date. If the `0.7.x` line is maintained on a separate branch from `main`, the fix likely needs to be cherry-picked/backported.
**Environment**
- Dioxus versions tested: 0.7.9 (3e43ffa), 0.7.10 (57d6794), 0.8.0-alpha.1 (0dbfab5)
- OS: Windows 11, tested both locally and on clean `windows-latest` GitHub Actions runner
- App platform: desktop (NSIS bundle target)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading PR #5619 and comparing its fix with the 0.7.10 tag and the maintained 0.7.x release line. Reproduce `dx bundle --release` on Windows using the directory resources in the issue, then verify that the backported fix copies those resources successfully in the affected 0.7.x release.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- build-system, cli, release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100