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.