Bug 8740 - compress ("-z") should be ignored if both src and dst are local
Summary: compress ("-z") should be ignored if both src and dst are local
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All All
: P5 trivial (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2012-02-02 17:33 UTC by john
Modified: 2020-07-26 07:27 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description john 2012-02-02 17:33:37 UTC
I once read the manual and remembered my favorite combination of parameters, which includes "-z"
A couple of days ago I manually started a rsync copy between a local source and a local destination. Today after screen -x I discovered the rsync is still running and taking 95% of the cpu. After a bit of wtf'ing around I finally carefully looked at rsync parameters and noticed my "-z" parameter.

Stopping rsync and restarting without compression brought disk traffic back to expected.

Truth is I never expected compression to be enabled when copying from local to local: why would rsync activate compression if both source and destinations are local, anyway?

A default behaviour to match this expectation would probably save others.

Comment 1 Brian K. White 2012-02-02 18:23:46 UTC
No please do not. If I specify an option, I want that option. If I do not want that option, I will not specify that option.

At most, add a new option that modifies the behavior of -z a la --skip-compress.

It's true I can't honestly think of a specific reason off hand, other than benchmarking and intentionally exercising (not invalid uses already), where I'd want to -z locally, I don't think it would even help where "local" includes nfs/samba mounts,


It's also true that since I first used rsync in... 1998 or 1999, I never considered this a problem. One mans automatic convenience is another mans "dammned automagical behavior is doing what makes sense in the common case _at the expense of_ what I need in this case".
Comment 2 roland 2013-12-25 20:47:19 UTC
>why would rsync activate compression if both source and 
>destinations are local, anyway

Because you told rsync to do so. 

hereby, i also give my vote to NOT include such feature in rsync
Comment 3 Wayne Davison 2020-07-26 07:27:36 UTC
I also think rsync should do as it is told.