Hot answers tagged

158

Advantages of using .tar.gz instead of .gz are that tar stores more meta-data (UNIX permissions etc.) than gzip. the setup can more easily be expanded to store multiple files .tar.gz files are very common, only-gzipped files may puzzle some users. (cf. MelBurslans comment) The overhead of using tar is also very small. If not really needed, I still do ...


60

You are actually asking only half of the question. The other question being, "Why would I compress a tar file with gzip?". And the answer is not just that gzip makes the file smaller (in most cases): tar: stores filename and other metadata: mode, owner ID, group ID, filesize, modification time stores a checksum (for the header only) gzip: can store ...


34

You don't need the paranoia at all. GNU tar — and in fact any well-written tar program produced in the past 30 years or so — will refuse to extract files in the tarball that begin with a slash or that contain .. elements, by default. You have to go out of your way to force modern tar programs to extract such potentially-malicious tarballs: both GNU and BSD ...


29

There is a quite big advantage to using only-gzipped text files - the contents can be directly accessed with command-line tools like less, zgrep, zcat.


21

I would say it's likely that the people just don't realise they can use gzip/bzip2/xz without tar. Possibly because they come from a DOS/Windows background where it is normal for compression and archiving to be integrated in a single format (ZIP, RAR, etc). While there may be slight advantages to using tar in some situations due to the storage of metadata ...


18

With GNU tar, it's simply tar -xvf untrusted_file.tar in an empty directory. GNU tar automatically strips a leading / member names when extracting, unless explicitly not told otherwise with the --absolute-names option. GNU tar also detects when the use of ../ would cause a file to be extracted outside of the toplevel directory and puts those files in the ...


17

There is an important difference that could make using tar important under some circumstances: Besides the "metadata" that @jofel mentioned in his answer, tar records the filename in the archive. When you extract it, you get the original filename regardless of what the archive is called. In your case the tar archive and the file it contains have the related ...


11

What I was missing was --group=root in addition to --owner=root. tar -c --{owner,group}=root (possibly with an optional --numeric-owner) fully anonymizes the archive.


7

In addition to all the other answers, I've recently struck a scripting situation where only one file was expected, but a previous employee wrote the scripts with the possibility of more than one file being generated. So files were tarred and bzipped, then transferred, and expanded. When the process grew to the point it made a 4.3 GB file, it rolled over ...


6

You can use --numeric-owner, that will just put your UID (1000 or something similar on most systems) in the file. From man tar: --numeric-owner always use numbers for user/group names


6

To cover a few points the other answers haven't: First, look what's in the file before you extract it: tar -tvf untrusted_tar_file.tar If there's anything in there you don't trust or want to extract, don't extract the tarball. Second, extract the tarball as a non-root user that only has write access to the one directory you're extracting the tarball ...


4

The problem is that find finds the Webcam directory, too, and runs ls Webcam which lists all the files there. To only list files, not directories, tell find -type f


4

Your problem is that ls -lR will be executed for all files (which will display the files) and every directory (which will display the contents of the directory). If your directory-hierarchy would not be flat, but contain sub-directories, this would display the contents even more often, as -R tells ls to traverse subdirectories again. Instead you should ...


4

You asked tar to archive the files file2 and total.tar in the archive called file1, which it attempted to do. Unfortunately that means that file1 was overwritten, all you can get from it now is file2: tar tvf file1 (don't add a z in there, you didn't specify it when creating the archive). The only way you'll recover file1 is from backups.


3

tar: option requires an argument -- 'f' This gives it away -- tar's 'f' flag specifies the file to read or create. Since you were piping a (compressed) tar file in from curl, you just needed to tell tar that the "file" to read was stdin with a '-'.


3

Depending on the source (and weight you may attach), shar dates back to around 1980. In a form which you might recognize, that comes from Rich Salz's implementation introduced in 1988, and improved in stages over the next few years. shar was originally a convenience for bundling text files. uuencoding (a way to send binary files) has been around at least ...


2

You are mistaken, shell archivers did exist no later than 1980. They have been written for the usenet source archives in order to allow the archives to appear inside a mail. Tar is binary and cannot easily be in a usenet source archive.


2

The root cause of this problem is amazingly short: . (yes: a dot). Understand that find (without a dir) is equivalent to find .. From man find: If no paths are given, the current directory is used. And, when you execute find . the dot appears in the generated list ( Using only four files with distinct names to make it simple ): $ find ...


2

It sounds like something split the file. When you try to un-tar the .a file does it abort early? That's a hint that it is split. Is the .a file 4GB? That's another hint. Try concatenating the files on a machine that can handle large files... cp myfile.tar.a myfile_full.tar cat myfile.tar.b >> myfile_full.tar tar xvf myfile_full.tar


2

You need to extract them, but you don't need to store them on the disk : tar -xOf MainFile.tgz SubFile1.tgz | tar -xO SubFile2.tgz | tar -xO SubFile3.tgz | tar -x abc.txt The -O flags sets output to stdout and without -f tar will accept archive data from stdin.


2

I would tar a single file, to copy it preserving the timestamp (which is easily overlooked in downloads). File permissions and ownership are less important: download is a term that applies to systems which are not well integrated. Whether tar'd or not, it is standard practice to compress the file to make downloads faster — and avoid running out of ...


2

No, in general this isn't possible. A FTP server usually has commands to get information about files and directories and to store, retrieve, delete and rename files. Commands to mount devices and to send messages to users are also standardized but not implemented in current servers. See the list of FTP commands on Wikipedia for details. No RFC mentions a ...


2

You are using printf to escape the spaces, as well as quoting it "" If you omit the printf call, and use the original $d with double-quotes, you are good. f=`echo $d | tr ' ' '_' | tr -d ',.!'` # Clean the name t=$YEAR_DIR/$f.tar.gz ##d=$(printf '%q' "$d") escapes the spaces # echo tar czf $t "$d" # This outputs the command as expected ...


1

I have done a lot of research on this. You can do a test on the file with a word count but it will not give you the same number number as a du -sb adir. tar -tvOf afile.tar | wc -c du counts every directory as 4096 bytes, and tar counts directories as 0 bytes. You have to add 4096 to each directory: $(( $(tar -tvOf afile.tar 2>&1 | grep '^d' | wc ...


1

According to How do you extract an App's data from a full backup made through “adb backup”?, that is a compressed tar-file using the deflate method. The accepted answer in that thread points to a program which you might use: nelenkov/android-backup-extractor There also is this, which might work: Android Backup Extractor. The deflate method is one of those ...



Only top voted, non community-wiki answers of a minimum length are eligible