-
Notifications
You must be signed in to change notification settings - Fork 762
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
hardlinks pointing to itself should be skipped on extraction #1381
Comments
First, I'll point out that the system call trace above is perfectly normal. Libarchive optimistically assumes the directory already exists (it usually does). If it can't create the file then it will do the time-consuming check to see if the directory already exists and create it if necessary. The series of calls above is exactly what I would expect to see in that case. (Tar format does not require that directories be separately recorded at all; the dearchiver is expected to create any directories as needed.) Hard links pointing to themselves is indeed nonsense. No sane filesystem can represent such an object. I think it would probably make the most sense to skip and warn about such entries. I'd also be curious how this archive was created. I can't really think of how this would happen unless the filesystem was being modified during the archiving process in some way that managed to confuse the hardlink tracking logic. |
@kientzle I have not response from the author and have prepared a patch that detects this early in _archive_write_disk_header(). |
@kientzle @jsonn I can now reproduce the behavior with GNU tar: $ echo 1234 > file
$ tar -cf test.tar file file
$ tar -tvf test.tar
-rw-rw-r-- root/root 5 2020-05-25 17:03 file
hrw-rw-r-- root/root 0 2020-05-25 17:03 file link to file The second file is stored as a hard link to the first file, pointing to the same path. |
Oh. That. Hmmm.... I vaguely recall some discussion about this years ago on the GNU tar mailing list. I think this occurs mostly when someone specifies a directory to be backed up and a list of files to back up as well:
The program creating the archive can make this less likely by only generating hard link entries when the on-disk link count is greater than one. Libarchive used to do this. However, I don't think there's any strategy on the archiving side that can completely avoid this. (Consider the above where one or more files are actually hard linked to some totally separate directory.) Putting in a warning for the case where the link target is literally the exact same string would be good. I suspect that would suffice to address the most common cases of this. There are probably many ways to generate link entries that cannot be restored because they technically are self-referential. Maybe some of these would do it?
It might be quite hard to solve this in any very robust way. I suspect you could achieve it by being very clever about how you handle failure when trying to restore hard links, but I'm not sure it's worth it. |
Tarball: https://projects.horms.net/projects/kexec/kexec-tools/kexec-tools-2.0.17.tar.xz
MD5: f72c11e3bd80de23cae144ce8683d96b
The tarball seems to have some file entries out-of-order or something (
tar tf
doesn't show directories?):Originally reported to CMake here: https://discourse.cmake.org/t/externalproject-add-fails-to-extract-kexec-tools-2-0-17-tar-xz/1251
The text was updated successfully, but these errors were encountered: