Re: tar extract errors occurring rarely but with same symptoms

[Paul Eggert]

On 6/5/21 9:39 AM, Daniel Villeneuve wrote:

> And when a problem like the above occurs, our process tries it again and it 
> usually succeeds (that is, I've never witnessed two successive failures).

When you say "it usually succeeds", do you mean that you extract from 
the exact same tarball and it works sometimes, but not others? Or that 
you generate a new tarball and the extraction fails from the new tarball?

Can you supply an example of a tarball where extraction failed?


> # suspicious SIGCHLD
> wait4(47737, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 47737
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=47737, 
> si_uid=759245037, si_status=0, si_utime=674, si_stime=37} ---

That ooks OK to me; tar is being signaled that gzip exited.

> # some successful file time updates

Yes, these are from tar creating delayed symlinks (or hardlinks to 
symlinks) when the symlink contents are dicey and could have caused 
problems if they had been extracted earlier.

> # first errors
> newfstatat(AT_FDCWD, "XXXXXX_config/static/users", 0x7ffc9b136f50, 
> AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)

This looks like the start of another attempt to create a delayed 
symlink; the first step is to get the status of the placeholder file. 
Please go back to earlier parts of the strace output, and look for 
references to this same filename. What syscalls do you see?

In the original data, what is the file XXXXXX_config/static/users? I 
assume it's a symlink; what does it point to? Also, what's 
"XXXXXX_config" and "XXXXXX_config/static"? Are they symlinks to 
directories?

Was XXXXXX_config one of the files you explicitly mentioned when 
creating the tarball? Did it follow other files?

Please send along any data that could help us reproduce the bug. Thanks.