Fix symlink to same exterior location #1167
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* 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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.