Issue Summary

In Bitbucket 8.x version, the support zips created by the ATST plugin don't capture the "application-logs" when the $BITBUCKET_HOME/log is configured as a valid symlink.
The customer uses a symlink to store logs on a different disk that has more (and faster) storage. They have been doing this since Stash 2.x and currently do the same in Bitbucket 7.x version. They had no issues creating support zips with this setup of Symlink. However, in Bitbucket 8.x, when $BITBUCKET_HOME/log is set to a valid symlink to a different location then support zips did not capture the "application-logs".

This is reproducible on Data Center: yes

Steps to Reproduce

Able to replicate the issue with Bitbucket 8.9 by setting a valid symlink in the $BITBUCKET_HOME/log
To recreate:
1. set $BITBUCKET_HOME/log to a valid symlink to a different location

cd $BITBUCKET_HOME; ll
drwxrwxr-x  2 ubuntu ubuntu  4096 May 12 00:06 analytics-logs
drwxrwxr-x  4 ubuntu ubuntu  4096 Apr 25 20:59 bin
drwxrwxr-x  5 ubuntu ubuntu  4096 May 12 01:22 caches
drwxrwxr-x  2 ubuntu ubuntu  4096 Apr 25 20:59 export
-rw-rw-r--  1 ubuntu ubuntu    66 Apr 25 20:59 home.properties
drwxrwxr-x  3 ubuntu ubuntu  4096 Apr 25 20:59 lib
lrwxrwxrwx  1 ubuntu ubuntu    23 May  8 20:47 log -> /logs/stash/
drwxrwxr-x  3 ubuntu ubuntu  4096 May  8 16:28 logs
drwxrwxr-x  6 ubuntu ubuntu  4096 May 12 01:22 mesh
-rw-rw-r--  1 ubuntu ubuntu 16384 Apr 27 01:25 mesh.mv.db
-rw-rw-r--  1 ubuntu ubuntu   567 Apr 27 00:29 mesh.trace.db
drwxrwxr-x  3 ubuntu ubuntu  4096 Apr 25 20:59 plugins
drwxrwxr-x  7 ubuntu ubuntu  4096 May 11 16:54 shared
drwxrwxr-x 31 ubuntu ubuntu  4096 May 12 01:22 tmp

2. start Bitbucket 8.9 
3. observe that bitbucket starts and logs are created and updated
4. create a support zip
5. observe the lack of application-logs folder

Expected Results

Bitbucket 8.9.x support zips should capture the "application-logs"

Actual Results

Bitbucket 8.9 support zip does not capture the "application-logs" and it does not follow symlinks for log folders. Bitbucket prior to version 7.x could follow symlinks for log files.

Workaround

Currently, there is no known workaround for this behavior. A workaround will be added here when available