-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symlinks are being followed and thus backing up the wrong jar #26
Comments
I agree. This can be better controlled using the Take a look at #14 |
Thanks for the report. We are looking into a fix. We may still consider using globs in the scan phase, in case (for whatever reason) symlinks point to jars outside the target folder that might still be loaded. |
Hey @jtran-cloudera, yes, no issue if there is links to file outside of the scan path, but then the script needs to run on that location separately. We can't have it just assume /opt/cloudera is the only place files will exist and follow all the symlinks and then fail to take a backup of the actual file and use the symlink in-stead by accident. |
There is a number of bit of code like
for jarfile in $targetdir/**/*.jar; do
Thus symlinks are being followed and bad things happen, espically with backup of the link name and not the actual file
consider using
for jarfile in $(find ${targetdir} -type f -name "*.jar") ; do
The text was updated successfully, but these errors were encountered: