Modification time of an element with an open workspace propagates into consumer element's sandbox

Open
#2,186 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
build-system

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.

Description

bug

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
Dominant language
Python
Stars
144
Forks
45
Avg merge
20h 38m
Merged PRs (30d)
6

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/buildstream

All issues in apache/buildstream

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.