Currently when the source of a fork(-network) is deleted, the forked projects lose track of the LFS objects. After https://gitlab.com/gitlab-org/gitlab/merge_requests/17558 is merged, all projects in a fork network will have access to the LFS objects from any project in that LFS network. This is correct, since all forks can send merge requests to each other. To avoid projects losing track of LFS objects uploaded to any other project in the fork network, we should also create a new `LfsObjectsProject` for each LFS object in the project being forked. **Question:** Should we keep track of which `LfsObjectProject` was uploaded directly to the forked project and which one was "copied" during a fork? If so How? Answer: We don't: https://gitlab.com/gitlab-org/gitlab/issues/20042#note_257180920 ___ ### Create `LfsObjectForkNetwork` model <details> To avoid projects losing track of LFS objects uploaded to any other project in the fork network, we should also link the LFS objects to the fork network. This would mean adding a new model: ```ruby class LfsObjectForkNetwork belongs_to :fork_network belongs_to :lfs_object end ``` Then we could check that for accessibility if the LFSObject was not linked to the project directly. When a project is forked, we would automatically need to create all the `LfsObjectForkNetwork` records in the [`Projects::ForkService`](https://gitlab.com/gitlab-org/gitlab/blob/cbc0a56d92e2340df37b75c553d08eb4395947e5/app/services/projects/fork_service.rb#L29). If a project is part of a fork network, we need to create a `LfsObjectForkNetwork` when a new LFS object is created in the [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cbc0a56d92e2340df37b75c553d08eb4395947e5/app%2Fcontrollers%2Fprojects%2Flfs_storage_controller.rb#L85) and the [`Lfs::FileTransformer`](https://gitlab.com/gitlab-org/gitlab/blob/cbc0a56d92e2340df37b75c553d08eb4395947e5/app%2Fservices%2Flfs%2Ffile_transformer.rb#L75). In this case, we would no longer be [creating an `LfsObjectProject` for the root of the fork network](https://gitlab.com/gitlab-org/gitlab/blob/cbc0a56d92e2340df37b75c553d08eb4395947e5/app%2Fcontrollers%2Fconcerns%2Flfs_request.rb#L115), but for the project it was created for. So no more [`Project#lfs_storage_project`](https://gitlab.com/gitlab-org/gitlab/blob/cbc0a56d92e2340df37b75c553d08eb4395947e5/app%2Fmodels%2Fproject.rb#L1324) as all LFS objects should be stored on _self_. We would need to backfill the `LfsObjectForkNetwork` records for all projects that are currently part of a fork network. </details> ### Original issue <details> We should figure out a way to handle this. Possible solutions: - Add the LFS objects to the forked project immeadiatly after the fork. The objects will then be handled independently of the fork network and count towards the quota of the namespace the fork resides in. - Add the LFS objects to all the forked projects when the root project is deleted. This could be a lot of forks, but it's handled in the background. - Keep track of the LFS-objects on a fork network. But to which quota do they count? ### Later created fork relations Another issue was brought up in gitlab-ce!18104: When a fork relation is created later on, the LFS objects of the fork might be somewhere else than the LFS objects of the parent. So at that point the objects of the fork become inaccessible, and the user should push the LFS objects again after creating the fork relation. The deletion now happens in the `Projects::ForkService#link_existing_project`, that might have to be reconsidered when implementing this: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22226#note_108780553 ### Newly uploaded LFS objects Right now, we're doing 2 different things: 0. When a user pushes LFS objects through their git-lfs client, the uploads go through workhorse and in [`Projects::LfsStorageController#upload_finalize!` and `#link_project!`](https://gitlab.com/gitlab-org/gitlab-ce/blob/4aa824e7059889c7b8badb4bd43cc44f9a01201f/app/controllers/projects/lfs_storage_controller.rb#L85) which uses the [`LfsRequest#storage_project`](https://gitlab.com/gitlab-org/gitlab-ce/blob/4aa824e7059889c7b8badb4bd43cc44f9a01201f/app/controllers/concerns/lfs_request.rb#L115). 0. When a user uploads through the web UI, this would be dealt with in this transformer, the LFS object would be linked to the *current* project and would become inaccessible. This is being changed in https://gitlab.com/gitlab-org/gitlab/merge_requests/17558 to all upload to the root of the fork network, but make LFS objects linked to the project itself accessible as well. We should decide on the _right_ project to link to LFS objects uploaded for a fork. ### Related issues This relates to https://gitlab.com/gitlab-org/gitlab-foss/issues/38883, and was brought up in https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15150#note_45541479 </details> /cc @DouweM @jramsay