0

I am trying to extracting a tarball with this sort of internal structure (simplified)

[edit: added toplevel dir] some_tarball.tar └── some_tarball/ ├── bin/ │   ├── a │   └── b └── share/ └── man/    └── man1/    ├── a.1.gz    └── b.1.gz

With the intention of installing this to /bin and /share dirs, I used the command sudo tar xzf some_tarball.tar --strip-components 1 -C /.

However, this ended up overwriting the entire directories with its contents (i.e. /bin only contains a and b afterwards) rather than merging the contents together. In the Overwrite control section of tar manpage, it seems to be only about overwriting existing files and the metadata of dirs, which is not the case.

Is there any way I can make tar demonstrate rsync-like behavior here? Thanks in advance!

P.S.: My /share is a symlink to /usr/share, if that matters.

Improve this question
9
  • If you had killed /bin your system would be pretty much dead. Are rm, cp, cat etc. still working? What are you trying to achieve with the component stripping? Commented Mar 24, 2021 at 11:26
  • @FelixJN Yes, it was pretty much dead, with all those basic utilities missing (also confirmed with ls -a /bin). I just now grabbed my installation media, mounted the squashfs partition and recovered it. As for the stripping, it is because of the presence of the toplevel directory in the tarball. Otherwise it would create /some_tarball, for example. (Sorry, I omitted that for simplicity in the tree structure) Commented Mar 24, 2021 at 12:18
  • OK. That still is not what tar should behave like. Not at all. I am sure you are aware of how to merge with cp or mv. But that tar-behavior is not right - And I couldn't reproduce it. Any odd aliases? Commented Mar 24, 2021 at 12:45
  • I have tested exactly what you did on an Ubuntu, with the archive that you link to, writing to a local directory instead, and the extraction of the archive does not remove existing files. I'm assuming that you did something differently from what you are showing in the question. Commented Mar 24, 2021 at 12:55
  • I had the same behavior happening with tar when reinstalling some distros; essentially i just tared some directory in / (mainly etc and some other ones) and when untarring, i had to cd into the target dir (tried with the -C flag too) but it had the same result as you noticed (with missing basic command)...The only way to solve this was to use cp or mv as the other mentioned. Commented Mar 24, 2021 at 16:06

1 Answer 1

Reset to default
1

If originally /bin is a symlink then the command you used will remove the symlink and create a new directory in its place.

Read more in the manual (emphasis mine):

When reading from an archive, the --dereference (-h) option causes tar to follow an already-existing symbolic link when tar writes or reads a file named in the archive. Ordinarily, tar does not follow such a link, though it may remove the link before writing a new file. […]

The --dereference option is unsafe […]

Note a directory is also a file.

You used neither --dereference nor -h Removing the link is what probably happened.

The directory the link pointed to is still somewhere, its content was not deleted. Still, since tools in /bin are quite important, your OS may be crippled. To fix this you need to recreate the original link: remove the new /bin directory and use ln -s target /bin.

Unfortunately I cannot tell what the target of the link was, you need to guess or find out what the target should be. Maybe /usr/bin.

Similarly with /share.

If you are still logged in or if you can log in anew then the fix should be technically possible because all tools you need should be somewhere. If you have lost the access (e.g. you cannot log in because /bin/bash is your login shell and it's not there) then booting a live distro and fixing from there is an option.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.