Snapcraft should consider dump part's file permission change as part changed
Metadata
Current evaluation
Dump/local parts still ignore chmod-only source changes; craft-parts checks mtimes but not modes, requiring a manual clean after permission changes.
Suggested action: keep open
Reason: The report is valid and still reproduces: craft-parts' local-source staleness check compares only st_mtime for files and directories, so a chmod that does not update mtime remains undetected. A maintainer acknowledged the report, several users confirmed it through Snapcraft 8.3.1, and the current implementation still omits permission metadata.
Evaluated by: mr-cal-bot
Impact:
42
Quick Win:
18
Complexity:
48
Confidence:
94
Actionability:
84
Issue body
Currently, Snapcraft won't consider a part dirty if a file in the part's source has its UNIX file permission changed (e.g. `chmod +x`), it should do so so that one doesn't need to clean the part manually.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
42
Quick Win:
18
Complexity:
48
Confidence:
94
Actionability:
84
|
keep open | Dump/local parts still ignore chmod-only source changes; craft-parts checks mtimes but not modes, requiring a manual clean after permission changes. | |
| stealth/space-bunny-alpha |
Impact:
48
Quick Win:
13
Complexity:
62
Confidence:
89
Actionability:
72
|
keep open | Source mode changes such as chmod +x leave dump parts incorrectly clean, requiring manual snapcraft clean. Acknowledged in 2019 and reported again on Snapcraft 8.3.1 in 2024; no fix is identified. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
11
Complexity:
40
Confidence:
70
Actionability:
60
|
keep open | craft-parts dump plugin does not detect source file permission changes as dirty, requiring manual part clean. Valid feature request, open with no maintainer response. | |
| qwen/qwen3.8-27b |
Impact:
30
Quick Win:
18
Staleness:
85
Complexity:
40
Confidence:
60
Support Request:
5
|
needs triage | Snapcraft's dump part doesn't mark a part dirty when a source file's UNIX permissions change (e.g. chmod +x), forcing manual clean. Reported 7+ years ago, no comments, no maintainer activity, and the underlying dirty-check logic has since moved to craft-parts. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
20
Confidence:
90
Support Request:
10
|
close stale | Requests Snapcraft to track UNIX file permission changes in dump parts as dirty state changes to avoid manual cleanups. Unaddressed for over 7 years with zero maintainer interaction. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
20
Confidence:
90
Support Request:
10
|
close stale | Snapcraft ignores UNIX permission changes in dump part sources when determining if a part is dirty, requiring manual cleaning. The issue remains open with no maintainer response or comments after over 7 years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
20
Confidence:
80
Support Request:
10
|
close stale | Snapcraft ignores UNIX permission changes in dump part sources when determining if a part is dirty, requiring manual cleanup. Unassessed for over 7 years. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Duplicate Of:
snapcraft (launchpad)#1889081
(confidence 94%)
Its title describes the same missing detection of permission-bit changes and need to re-clean a part.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1889081 snapcraft does not detect need to re-clean part after permission bits change on file | snapcraft (launchpad) | open | Dump parts can retain stale file permissions because change detection compares modification times only; the issue remains open, with a maintainer suggesting ctime. |