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
RFC: Copy symlinks as symlinks and add missing symlink targets at the end #2740
Labels
Milestone
Comments
Code lines that call
|
Stale issue message |
Stale issue message |
@jsmeix Unfortunately closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
When creating the recovery system files and directories get copied.
The problem is how to deal best with (possibly dangling) symlinks.
See #2739
therein in particular
#2739 (comment)
that reads (a bit adapted excerpts):
Perhaps we should in general not specfically care about symlinks
in the individual scripts i.e. that in general we just copy symlinks as symlinks
and leave it completely to
build/default/490_fix_broken_links.sh
to fix the broken symlinks inside the recovery system?
On first glance this looks wrong because each code part should do its task right
but on a second glance fix only actually broken symlinks in a generic script at the end
could have general advantages.
Example:
Assume in the original system there are
then
cp -L
results that in the recovery systemboth /path1/to/symlink1 and /path2/to/symlink2 are regular files
with identical contents as /path/to/huge_file
cf. #2739 (comment)
so
cp -L
can result needlessly duplicated contentin particular when /path/to/huge_file gets included anyway.
Another reason is that in practice it gets rather complicated
to deal correctly with symlinks at each code place
(e.g. see #2739)
so it could be better in practice to not care at each code place
and only fix what actually needs to be fixed at the end by a generic script.
The text was updated successfully, but these errors were encountered: