tar extraction depends on filename?

Question

I often download tarballs with wget from sourceforge.net.

The downloaded files then are named, e.g SQliteManager-1.2.4.tar.gz?r=http:%2F%2Fsourceforge.net%2Fprojects%2Fsqlitemanager%2Ffiles%2F&ts=1305711521&use_mirror=switch

When I try to

tar xzf SQliteManager-1.2.4.tar.gz\?r\=http\:%2F%2Fsourceforge.net%2Fprojects%2Fsqlitemanager%2Ffiles%2F\&ts\=1305711521\&use_mirror\=switch

I receive the following error message:

tar (child): Cannot connect to SQliteManager-1.2.4.tar.gz?r=http: resolve failed

gzip: stdin: unexpected end of file
tar: Child returned status 128
tar: Error is not recoverable: exiting now

After renaming the file to foo.tar.gz the extraction works perfect.

Is there a way, that i am not forced to rename each time the target file before extracting?

Solution 1

The reason for the error you are seeing can be found in the GNU tar documentation:

If the archive file name includes a colon (‘:’), then it is assumed to be a file on another machine[...]

That is, it is interpretting SQliteManager-1.2.4.tar.gz?r=http as a host name and trying to resolve it to an IP address, hence the "resolve failed" error.

That same documentation goes on to say:

If you need to use a file whose name includes a colon, then the remote tape drive behavior can be inhibited by using the ‘--force-local’ option.

Solution 2

When you download with wget, specify the output file name with the -O option.

wget "http://domain.com/file.tgz?crazy=args&stuff=todelete" -O file.tgz

This will cause the file to save with the given filename and save you the trouble or renaming it. And no, you are not the only one that wishes sourcefourge wouldn't be so dumb as to pass out files with the url parameters attached.

Solution 3

Download using

wget --trust-server-names URL

That way wget will save with the correct file names. By default it uses the last component in the URL

For eg

wget --trust-server-names http://sourceforge.net/projects/sqlitemanager/files/sqlitemanager/1.2.4/SQliteManager-1.2.4.tar.gz/download

Solution 4

As cited above, the : (column) make tar think it's a remote file. So we need to enforce the fact it's local.

Fail

$ tar czf "back$(date -u +"%H:%M").tar.gz" ./
tar (child): Cannot connect to back10: resolve failed
tar: Child returned status 128
tar: Error is not recoverable: exiting now

Solution

Explicit the fact it's a local file by appending ./ (current directory) and quoting correctly:

$ tar czf ./"back$(date -u +'%H:%M').tar.gz" ./
tar: .: file changed as we read it

The warning is due to the fact I'm creating in the source directory.

Solution 5

For already downloaded files, this should work:

tar xzf - < SQliteManager-1.2.4.tar.gz*

View more solutions

Comments

[ArtOfWarfare]

Note that --force-local has to be added before the f... when I first tried this it was giving me an error message about how there's no such file as --force-local. Maybe this is too "no duh" but I didn't recognize the mistake I made until 5 minutes later.

[camh]

@ArtOfWarfare: f takes an argument that is the tarfile. You cannot put --force-local between the f and its argument, but that is standard for all programs, not just tar and not just -f. You can put --force-local after f as long as it is also after the argument to f.

[ArtOfWarfare]

like I said in my comment, maybe it’s too “no duh”. I use tar like this tar -cvzf ... and don’t even think about what each flag does really 99% of the time - it’s just reflexive that that’s how I make a tar.gz.

[pcworld]

This isn't SourceForge's fault, but wget's. Use the --content-disposition flag to save with the server-specified filename (but beware of the security implications, as SourceForge can then write to an arbitrary filename).

[Dr. Dan]

On this note, to be more helpful on what these two (@ArtOfWarfare and @camh) are saying here is an example: tar zxvf C:\Users\jdoe\Documents\tarfile.tgz --force-local

[Alireza Mohamadi]

Much better than using a long flag. Also I believe remote host downloading is useless option while there are specific tools to achieve this purpose.

[Jeff Schaller]

Your example works because it does not duplicate the situation in the question. From the accepted answer: "If the archive file name includes a colon (‘:’), then it is assumed to be a file on another machine"

[Jeff Schaller]

Your example works because it does not duplicate the situation in the question. From the accepted answer: "If the archive file name includes a colon (‘:’), then it is assumed to be a file on another machine"