Uploaded image for project: 'Bitbucket Server'
  1. Bitbucket Server
  2. BSERV-9761

Repository alternates are not updated when BITBUCKET_HOME is symbolic link and its target changes

    XMLWordPrintable

    Details

      Description

      When Bitbucket Server tracks the home directory's location, it needs to consider the canonical path, not just the configured path. If $BITBUCKET_HOME, or any of its parent directories, is a symbolic link, the tracking needs to "peel" those symbolic links.

      History

      When forks were added in Stash 2.4.0, they were built using Git alternates to help manage on-disk storage. Alternates are stored as absolute paths. As a result, moving the $BITBUCKET_HOME directory requires alternates to be rewritten. If $BITBUCKET_HOME is a symbolic link, and the target of the link is updated, since the configured value has not changed, the system doesn't detect that as moving the home directory and does not rewrite alternates.

      Problem description

      When a new fork is created, its alternate is created by git clone --shared. Unlike Bitbucket Server, git clone "peels" symbolic links along the repository path to get a canonical, absolute path. That means if $BITBUCKET_HOME is a symbolic link, its target path is used. This results in alternates that become invalid when the symbolic link's target is moved.

      To illustrate this better, consider an install where $BITBUCKET_HOME is set to /var/atlassian/application-data/bitbucket. If $BITBUCKET_HOME was updated to, say, /var/atlassian/application-data/bitbucket-home, the system would automatically rewrite alternates to ensure forked repositories remain valid.

      By comparison, if /var/atlassian/application-data/bitbucket was a symbolic link to /mnt/bitbucket-home, if the target was moved to, say, /mnt/larger-volume/bitbucket, but $BITBUCKET_HOME remained /var/atlassian/application-data/bitbucket, the system would not attempt to rewrite alternates. However, when forks were created, git clone would have "peeled" /var/atlassian/application-data/bitbucket/shared/data/repositories/42/objects and written the alternate as /mnt/bitbucket-home/shared/data/repositories/42/objects instead. As a result, the fork would become "corrupted", because it would no longer be able to access borrowed objects.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              bturner Bryan Turner
              Votes:
              7 Vote for this issue
              Watchers:
              23 Start watching this issue

                Dates

                Created:
                Updated:

                  Backbone Issue Sync

                  • BbS JAC Mirror <> Bitbucket Server
                    Synced with:
                    BBSJAC-273
                    Issue sync status:
                    UP TO DATE
                    Last received:
                    Last sent: