No, it's very unatomic. This can get you in big trouble if you gzip a file that's being occasionally appended to, like a Web log.
Gzip reads, creates the .gz file (with current timestamp), copies the original file's timestamp, then deletes the original.
Certain interruptions may leave a stray, unfinished .txt.gz
file right next to the .txt
file. This then creates a data integrity issue: Which is the real file? Is this
- a gzip which failed, leaving an incomplete / corrupted
.txt.gz
? Or
- a gunzip which failed, leaving an incomplete / truncated
.txt
file? Or
- A file successfully gzipped into
txt.gz
, and a newly created .txt
file?
(This last happens when you go into your HTTP log directory and go gzip *
).
I generally find it's prudent to sort this out by hand, unless you know exactly what happened because you just did it.
Fortunately gzip usually operates serially so you should only have this problem with one file. Paralleling gzip isn't a good idea - even though it'll use CPU more fully, it'll thrash the disk forcing it to read several files at once, greatly slowing down all gzip's. SSD or RAMdisk, on the other hand...
CTRL+Z
instead ofCTRL+C
, then kill or resume the interrupted job (it answers with a numbern
[--[n]+ Stopped-- gzip ...
] then you can resume with%n
or withfg
, or withbg
... in the same way you can kill it withkill %n
). – Hastur Aug 23 '19 at 17:32