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

Open
#5,723 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.