-
Notifications
You must be signed in to change notification settings - Fork 148
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
Fix symlink to same exterior location #1167
base: main
Are you sure you want to change the base?
Conversation
* Symlinks to a directory inside of /etc/pki were being created as empty directories. * Note: unittests being added for both this problem and a second problem: two links to the same external file will be copied as two separate files but ideally we want one to be a copy and the other to link to the copy. The unittests for the second problem are commented out. Fixes: https://issues.redhat.com/browse/RHEL-3284
In the present code, when we have two separate links to the same file outside of /etc/pki, the real file is copied to the location of both links. The problem with this is when the user makes changes to the file in the future, they will have to edit both files whereas before they would only have had to edit one of the files (since they linked to the same underlying file). Example: Host: lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileA -> /etc/sourceFile lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileB -> /etc/sourceFile Becomes: -rw-r--r--. 1 badger badger 12 Jan 22 03:43 fileA -rw-r--r--. 1 badger badger 12 Jan 22 03:43 fileB fileA and fileB are separate copies of /etc/sourceFile. This change makes it so anytime two links eventually point to the same exterior file, the first link will be copied and the second link will becone a symlinks to that copy like this: -rw-r--r--. 1 badger badger 12 Jan 22 03:43 fileA lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileB -> /etc/pki/fileA This is the behaviour even if the second link went through several other exterior links to reach the same sourceFile (but not if there is another interior link in between). Example: Host: lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileA -> /etc/sourceFile lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileB -> /etc/sourceFile lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileC -> /etc/external-to-same-file lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileD -> /etc/external-to-interior-link lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 /etc/external-to-same-file -> /etc/sourceFile lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 /etc/external-to-interior-link -> pki/fileB Becomes: -rw-r--r--. 1 badger badger 12 Jan 22 03:43 fileA lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileB -> /etc/pki/fileA lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileC -> /etc/pki/fileA lrwxrwxrwx. 1 badger badger 13 Jan 22 03:42 fileD -> /etc/pki/fileB The drawback to the end user is that, unless you trace all the way through the chain of symlinks, it is confusing that fileA ends up being a real file and fileC ends up pointing to it. It's not immediately obvious how the two are related. The advantage is if the end user makes any changes to either fileA or fileC, then the changes will be visible in both files. This is the behaviour that existed on the host system.
Thank you for contributing to the Leapp project!Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp from PR#42, use It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported,
[Deprecated] To launch on-demand regression testing public members of oamg organization can leave the following comment:
Please open ticket in case you experience technical problem with the CI. (RH internal only) Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra. |
Note: #1166 must be merged first and then this PR should be rebased.
In the present code, when we have two separate links to the same file outside of /etc/pki, the real
file is copied to the location of both links. The problem with this is when the user makes changes
to the file in the future, they will have to edit both files whereas before they would only have had
to edit one of the files (since they linked to the same underlying file). Example:
fileA and fileB are separate copies of /etc/sourceFile.
This change makes it so anytime two links eventually point to the same exterior file, the first link will be copied and the second link will becone a symlinks to that copy like this:
This is the behaviour even if the second link went through several other exterior links to reach the
same sourceFile (but not if there is another interior link in between). Example:
The drawback to the end user is that, unless you trace all the way through the chain of symlinks, it
is confusing that fileA ends up being a real file and fileC ends up pointing to it. It's not
immediately obvious how the two are related.
The advantage is if the end user makes any changes to either fileA or fileC, then the changes will
be visible in both files which is the behaviour that existed on the host system.