Artifacts can get corrupted while running integration commands about bst-staging HOT 7 CLOSED

In GitLab by [Gitlab user @samthursfield] on Jun 6, 2017, 10:36

A few years ago Adam Coldrick implemented this feature for Morph using overlayfs or unionfs-fuse. This never got merged to master.

The proposed changes are here -- long since abandoned but maybe useful as they were tested and working at one point.

1. https://gerrit.baserock.org/#/c/290/
2. https://gerrit.baserock.org/#/c/289/
3. https://gerrit.baserock.org/#/c/288/

from bst-staging.

In GitLab by [Gitlab user @tristanvb] on Jun 7, 2017, 10:29

mentioned in commit 70914c8

from bst-staging.

In GitLab by [Gitlab user @tristanvb] on Jun 11, 2017, 14:00

This is currently implemented in the 'safe-hardlinks' branch and seems to be working well.

Need to just check that everything is working, I think some cases of bst shell are broken by the API churn so will merge this after a little bit of cleanup.

from bst-staging.

In GitLab by [Gitlab user @tristanvb] on Jun 13, 2017, 13:04

The new SafeHardlinks fuse layer is now implemented in master.

Essentially this means:

• If the sandbox root is read-only, the fuse layer is not used
• If the sandbox root is read-write, it is protected by the fuse layer
• Mount points for staged Sources or build output are not protected by the fuse layer

The SafeHardlinks fuse layer acts as a regular passthrough except that in the cases where:

• File will be modified
  • File is going to be opened for writing or
  • File is going to change ownership or
  • File is going to change mode bits
• And the file is not a directory (which cannot be hardlinked)
• And the file has more than one link (it is a hardlink)

Then the file will first be copied into a temporary directory, and replaced with it's copy, ensuring it is no longer a hardlink into the ostree repository or checkout.

from bst-staging.

In GitLab by [Gitlab user @tristanvb] on Jun 13, 2017, 13:04

closed

from bst-staging.

In GitLab by [Gitlab user @toscalix] on Jul 25, 2018, 14:36

marked this issue as related to #504

from bst-staging.

In GitLab by [Gitlab user @toscalix] on Jul 25, 2018, 14:36

removed the relation with #504

from bst-staging.