Modification time of an element with an open workspace propagates into consumer element's sandbox
- Dominant language
- Python
- Stars
- 140
- Forks
- 45
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 6
Description
When an element has a dependency with an open workspace, that dependency's artifacts get staged with their real mtimes instead of the magic timestamp. This can cause differences between builds with and without the workspace.
# Steps to reproduce
A small project to reproduce the issue:
```
.
├── a.txt
├── elements
│ ├── a.bst
│ ├── alpine.bst
│ └── b.bst
└── project.conf
```
The context of `a.txt` are irrelevant, it can be left empty. `elements/a.bst` carries `a.txt`:
```
kind: import
sources:
- kind: local
path: a.txt
config:
target: /
```
`elements/b.bst` has `a.bst` and `alpine.bst` as build dependencies:
```
kind: manual
build-depends:
- alpine.bst
- a.bst
```
project.conf and alpine.bst are set up to pull alpine image
`alpine.bst`:
```
kind: import
description: |
Alpine Linux base runtime
sources:
- kind: tar
# This is a post doctored, trimmed down system image
# of the Alpine linux distribution.
#
url: alpine:integration-tests-base.v1.x86_64.tar.xz
ref: 3eb559250ba82b64a68d86d0636a6b127aa5f6d25d3601a79f79214dc9703639
```
`project.conf`:
```
# Unique project name
name: bug-repro
# Required BuildStream version
min-version: 2.7
# Subdirectory where elements are stored
element-path: elements
aliases:
alpine: https://bst-integration-test-images.ams3.cdn.digitaloceanspaces.com/
```
When no workspace is open, building `b.bst`, opening its build sandbox, and checking the mtime of `a.txt` shows that all is well, and modification time is normalised:
```
$ bst build b.bst
...
$ bst shell --build b.bst
...
[20440600@b.bst:/buildstream/repro/b.bst]$ stat /a.txt
File: /a.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 31h/49d Inode: 2 Links: 1
Access: (0644/-rw-r--r--) Uid: (1876721912/ UNKNOWN) Gid: (1174200513/ UNKNOWN)
Access: 2011-11-11 11:11:11.000000000
Modify: 2011-11-11 11:11:11.000000000
Change: 2011-11-11 11:11:11.000000000
```
If `a.bst`'s workspace is opened first, the modification time is no longer the magic timestamp but the actual `a.bst`'s build time instead:
```
$ bst workspace open a.bst
...
$ bst build b.bst
...
$ bst shell --build b.bst
...
[e1f40f6c@b.bst:/buildstream/repro/b.bst]$ stat /a.txt
File: /a.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 31h/49d Inode: 3 Links: 1
Access: (0644/-rw-r--r--) Uid: (1876721912/ UNKNOWN) Gid: (1174200513/ UNKNOWN)
Access: 2011-11-11 11:11:11.000000000
Modify: 2026-08-25 11:06:30.000000000
Change: 2011-11-11 11:11:11.000000000
```
Contributor guide
Research direction
Start by reproducing the issue with the supplied project, comparing the build sandbox mtime for a.txt with and without `bst workspace open a.bst`. Trace how workspace artifacts are staged into `b.bst`'s sandbox. Done when the workspace and non-workspace builds both preserve the magic timestamp.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100