← Back to issue list

`charmcraft pack` does not handle updating a file's execution permissions without a `charmcraft clean`

View original Github issue

Metadata

Project
charmcraft
Number
#907
Type
issue
State
open
Author
ca-scribner
Labels
—
Created
Updated
Closed
—

Current evaluation

charmcraft pack keeps stale file permissions in the build container unless `charmcraft clean` is run; root cause is craft-parts' outdated check only comparing mtime. Reproduced upstream, workaround `touch` documented, still open.

Suggested action: keep open

Reason: The maintainer reproduced it ("I reproduced the problem, and opened a new issue in the Craft Parts library") and filed canonical/craft-parts#311, which is still open; I verified at craft-parts HEAD that `LocalSource.check_if_outdated` (craft_parts/sources/local_source.py) still flags files solely via `os.lstat(path).st_mtime >= target_mtime`, with no st_mode comparison, so the bug is not fixed. Two independent reporters confirmed it (rsyring's lint error 'The entrypoint file is not executable' and carlcsaposs-canonical's 'some files to not be detected as updated'), and an internal ticket CRAFT-3250 exists, so it is triaged and valid — but the fix lives in craft-parts, not charmcraft, and the only charmcraft-side remedies are documenting the `touch`/`clean` workarounds. Age (1445 days) is not a reason to close while the upstream issue remains open.

Evaluated by: mr-cal-bot

Impact: 45 Quick Win: 17 Complexity: 45 Confidence: 82 Actionability: 70

Issue body

# What happened `charmcraft pack` will error out if you try to pack a charm with a `src/charm.py` that does not have execution permission on the file. If you fix the permissions and then `pack` again, it will respond with the same message. You need to `clean` the charmcraft env before packing for this to work as expected. # What did you expect If I change the permissions on a file locally, I expect `charmcraft pack` to either reproduce those changes in my container or error specifically telling me it cannot do that. Instead, the current implementation quietly ignores some differences between my local files and container, leading users to continue debugging things they've already fixed just because it is not transparent whether the fix made it into the container. # Reproduction ```bash git clone https://github.com/canonical/template-operator cd template-operator chmod a-x src/charm.py charmcraft pack # Fails with an error saying the charm file is not executable chmod a+x src/charm.py charmcraft pack # Still fails with an error saying the charm file is not executable charmcraft clean charmcraft pack # Works ``` # Additional comments A mitigation is to use `charmcraft clean` liberally whenever you're not sure if something will propagate to the container, but that is a poor user experience. Cold-start for charmcraft is slow (minutes vs 10's of seconds) and very disruptive to an iterative workflow

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 45
Quick Win: 17
Complexity: 45
Confidence: 82
Actionability: 70
keep open charmcraft pack keeps stale file permissions in the build container unless `charmcraft clean` is run; root cause is craft-parts' outdated check only comparing mtime. Reproduced upstream, workaround `touch` documented, still open.
qwen/qwen3.6-35b-a3b
Impact: 40
Quick Win: 17
Complexity: 40
Confidence: 80
Actionability: 70
keep open charmcraft pack ignores file permission changes without clean; root cause in craft-parts#311 (check_if_outdated only compares st_mtime, not st_mode). Still open.
qwen/qwen3.8-27b
Impact: 55
Quick Win: 25
Staleness: 65
Complexity: 55
Confidence: 85
Support Request: 10
keep open charmcraft pack ignores local file permission changes (e.g., chmod +x on src/charm.py) until a full charmcraft clean, causing confusing lint errors. Maintainer reproduced and filed upstream craft-parts#311; still unfixed.
qwen/qwen3.6-35b-a3b
Staleness: 80
Complexity: 65
Confidence: 70
Support Request: 10
keep open charmcraft pack ignores file permission changes without a clean, causing silent build failures. Acknowledged and tracked upstream, but unlabelled and inactive for over a year.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 55
Confidence: 80
Support Request: 10
keep open charmcraft pack fails to detect file permission changes without a clean. Maintainer reproduced it, linked to upstream craft-parts, and provided a workaround. Issue remains open but inactive for over 10 months.
qwen3.6-35b-a3b-mtp-q6
Staleness: 88
Complexity: 55
Confidence: 70
Support Request: 10
keep open Acknowledged bug where charmcraft pack fails to detect file permission changes without clean. Maintainer reproduced it, linked to upstream craft-parts issue, and provided a workaround. Awaiting upstream resolution.

Update history

No update history recorded yet.

Related work

  • Blocked By: craft-parts#311 (confidence 92%)

    Upstream 'Permission changes in files are not detected' issue, still open; local_source.check_if_outdated compares only st_mtime, confirming the root cause is unfixed.

  • Related To: charmcraft#1160 (confidence 82%)

    Same class of defect: pack ignores local file changes (charmcraft.yaml/build-snaps) without a clean; blocked by craft-parts#496, also open.

  • Related To: charmcraft#736 (confidence 55%)

    Explicitly linked by carlcsaposs-canonical as 'might also be related'; that issue is closed as non-reproducible LXC corruption, so it adds little.

Related issues

Issue Project State Summary Similarity
#1160 `charmcraft pack` does not recognize updated `charmcraft.yaml` file charmcraft open Tracked upstream: charmcraft pack ignores build-snaps channel changes in charmcraft.yaml unless clean is run. Root cause is craft-parts#496 (build-snaps missing from properties_of_interest), still unfixed; charmcraft only needs a craft-parts bump once patched.
75%
#710 `charmcraft pack` retains no longer existing files from previous packs charmcraft open Repacking reuses the part's build container, so files deleted from the working tree linger in the resulting charm until `charmcraft clean <part>`. Maintainers confirmed it still reproduces; root cause tracked upstream in craft-parts#851.
74%
#746 `charmcraft pack` for existing environment does not remove files that have been deleted charmcraft closed Closed as a duplicate of charmcraft#710 by maintainer facundobatativa (facundobatista) on 2022-04-13. #710 remains open, with the root cause tracked upstream in craft-parts#851.
73%