Should no-tweak mode become the default?

--===============0048918498==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="=-0fUNags0kvflyb2W05go"


--=-0fUNags0kvflyb2W05go
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is to continue my discussion with Carl from:

=EF=BB=BFhttps://bugzilla.samba.org/show_bug.cgi?id=3D5448

about whether no-tweak mode should become rsync's default when --inplace
is not specified. I'm eager to get some comments from other people on
this too.

On Thu, 2008-05-08 at 15:07 -0500, Bugzilla sent Carl's comment:
> I understand that but I think the reality is that the current default is
> behavior that is unwanted in real-life

Unwanted in many cases but not in some others, such as my example below.

> and causes serious security vulnerabilities.

A setup with the previous backup in the module is currently vulnerable;
however, since the tweaking behavior is documented, a responsible daemon
administrator would see the vulnerability and avoid such a setup in
favor of an alternative. Hence, I don't think we are obliged to rescue
irresponsible daemon administrators by changing the default, if that is
what you are implying here.

> > A user who changes the permissions on a
> > collection of large files and then mirrors it somewhere is not going to=
be
> > happy about the job taking several times as long as usual.
>=20
> This is an edge case where things would be a little slower.

Much slower if the files are multi-gigabyte disk images.

> But this is
> actually an argument _for_ my idea because this user's previous backups w=
ould
> be broken by the current behavior.

No, in the case I am thinking of, the user is mirroring the files to a
single destination, not creating a series hard-linked backups.

> If the user really wants the files modified
> in place regardless of the risk it makes sense to me for the user to expl=
icitly
> request that by using the "--inplace" option.

There are two reasons why the user might not want --inplace: =EF=BB=BFit up=
dates
the data at the destination path non-atomically, and it prevents the
delta-transfer algorithm from identifying movement of data from earlier
to later offsets. --tweak would work; the question is then whether it
is fairer for that user to start having to pass --tweak or for you to
have to pass --no-tweak.

I am not saying that this use case (of an attribute change to very large
files) by itself makes tweak mode a superior default to no-tweak mode.
I just think it should receive full consideration before we change the
default.

Matt

--=-0fUNags0kvflyb2W05go
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBII6oLC+xSYN/RlfsRAmMTAKCoVba5OLx18xwaGs0q/Uj5KP3DaACcD3uy
PXmAiRRg4kKnph3hzJ52SRc=
=1El4
-----END PGP SIGNATURE-----

--=-0fUNags0kvflyb2W05go--


--===============0048918498==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--===============0048918498==--