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
- a gunzip which failed, leaving an incomplete / truncated
.txt file? Or
- A file successfully gzipped into
txt.gz, and a newly created
(This last happens when you go into your HTTP log directory and go
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...