Skip to content
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

Open
starkjs opened this issue Dec 15, 2021 · 3 comments
Open

Symlinks are being followed and thus backing up the wrong jar #26

starkjs opened this issue Dec 15, 2021 · 3 comments

Comments

@starkjs
Copy link

starkjs commented Dec 15, 2021

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

@belugabehr
Copy link

I agree. This can be better controlled using the find command with the -f flag.

Take a look at #14

@jtran-cloudera
Copy link
Contributor

jtran-cloudera commented Dec 15, 2021

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.

@starkjs
Copy link
Author

starkjs commented Dec 19, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants