New answers tagged compression
You can try the --remove-files argument to tar. Say you want to compress everything on directory FOO, you would: tar -czf FooCompressed.tar.gz --remove-files FOO Arguments explained: c: create TAR z: compress using GZIP, you can switch to -j for BZIP2 or -J for LZMA(xz) f: output to file instead of of STDOUT remove-files: self explanatory
I normally never make zip files, so I'm no expert, but it looks like zip by default just adds files to an archive, so something like (untested - contains an rm command = potentially dangerous - Test yourself before risking your data): for f in $(ls --sort=size --reverse); do zip -9 archive.zip $f; rm $f; done in the directory, could probably do it.
If the largest file in the directory is less than 300GB (the amount of free space), the easiest option is to compress files individually rather than creating an archive; something like find directory -type f \! -name '*.xz' -print 0 | xargs -0 xz -9 will compress all non-compressed files in directory using xz at compression level 9. This will replaces ...
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 ...
There are a lot of good answers here that helped me get going but I ended up with this simple command: zgrep -e 'something to search for' *.gz
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 ...
Tar is especially useful for multiple files not written to a formal file system, it always has been. If for some reason there is on occasion, only 1 file to be written it is of no real consequence. I can dd my .tar.gz directly to /dev/sdx without regard to partition or file system. It may as well be tape. It is generally done because the script or process ...
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 ...
here a shorty with strong xz compression cd /ur/directory/where/the/content/is backupfile="`date +"%y-%m-%d`"; targetdir="/where/u/want" [ ! -f "$targetdir/$backupfile".tar.xz ] && tar -xJvf "$targetdir/$backupfile".tar.xz *
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 ...
gunzip -c $file | wc -c This will take a long time, but will give you the final size in bytes.
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.
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 ...
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 ...
No there is no chance of losing during compression. Only when the file is complete processed is the source deleted (that is, if you don't specify -k or --keep, in which case the source is not deleted at all).
Not reproduced here? $ shuf -i1-10000000 > t.in $ sort -S50M -T. t.in --compress-program=lzop # ^z $ file sort* | tee >(wc -l) > >(grep -v lzop) 7 $ fg # ^c $ sort --version | head -n1 sort (GNU coreutils) 8.25 What I'm guessing the issue is, is due to failure to fork() the compression process due to the large mem size, and then falling ...
You can use gs - GhostScript (PostScript and PDF language interpreter and previewer) as follows: Set pdfwrite as output device by -sDEVICE=pdfwrite Use the appropriate -dPDFSETTINGS. From Documentation: -dPDFSETTINGS=configuration Presets the "distiller parameters" to one of four predefined settings: /screen selects low-resolution output ...
Not just gzip, but attempting to compress a file which is already as small as possible can increase the size (because each method for compression has some overhead in the form of header, tables, etc). This is also referred to as negative compression. Further reading What's the most that GZIP or DEFLATE can increase a file size? Why GZip compression ...
Top 50 recent answers are included