X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org C294F385354A
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1690047243;
	bh=Ts6L0rVp2TOYiJ2+ZzosEzO1ijstRqFChUU3dySQQEc=;
	h=References:In-Reply-To:Date:Subject:To:Cc:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	From:Reply-To:From;
	b=A4aeSvxBhrihSYWiOkMXn0rkhpKLTmvYIlrmTyf1vBJQ05O+ToEDsTmlMk/oxL6T3
	EPYmGdXhq4zOgtCVHiWTB7yjmu4BBXS9J8CSyoLMO/3reQM3AAJvT3FIcNVMoelqo7
	nBOo5DGwSY3bNd9opaelF/XjYOPKxm7bWrRZ9Fmg=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 9C9043858CDA
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20221208; t=1690047227; x=1690652027;
	h=content-transfer-encoding:cc:to:subject:message-id:date:from
	:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
	:subject:date:message-id:reply-to;
	bh=MLY31MEuz8dpJBdxIjo1l4uq2SPHNyiTFwW1iZ5MQuw=;
	b=Spfk1+fCICu7BYreW0hXYabI+WBMGklYvbzsb/iAV1iCJovjKbYCTg54nC4tsVhNuR
	vLo4tL1/MYfEhDnUONZ6iL9LP1/ZmpQLMine6yNgOQMATBsMsMqRfJ4+iegGJLvcBiFR
	v27A4YH+v6NR2IfNAF5DWoy9JASRfJpJo0MKX3g56KO1J7ZcANXmzBtGhLGubPEz+p78
	5qdl691hJtsAkHuZa/zZ319RairkxHCipe9qrchcqoKa427rzjYdl6FoQWO8/aolGmcC
	XYuBaL6Pvy27otd0FTDZN4oFFRxoJjBU0IG3WgjPX5YwWux26J0+G2/DoHghdjyTWK6E
	KIJg==
X-Gm-Message-State:	ABy/qLYE8HhAVHp5XkXkxd6uNhdwNwpYMAPT58k50QdwKgpGcRonKUYO
	8NHmADcRnVs2nzG3iU723HO5jMtBhbDSbJHGxNBYs46CTY4Yka5u
X-Google-Smtp-Source:	APBJJlHmRSAXd801mUgTuooGd6x7dsZF4GYmHwQyTiKXDqcEA6mXvFYcpALtD2PPSFGz26eVfqUtRiePBU3LK613594=
X-Received:	by 2002:a4a:dcd1:0:b0:569:a08a:d9c5 with SMTP id
	h17-20020a4adcd1000000b00569a08ad9c5mr3311948oou.0.1690047226928; Sat, 22 Jul
	2023 10:33:46 -0700 (PDT)
MIME-Version:	1.0
References:	<a243a980-66ba-e01e-298a-60a221efd7b4 AT jhmg DOT net>
	<ba2c0efe-7892-6eb3-9828-ca8d83643939 AT Shaw DOT ca>
	<a5e19263-d820-7737-16eb-16e6429dd586 AT jhmg DOT net>
In-Reply-To:	<a5e19263-d820-7737-16eb-16e6429dd586@jhmg.net>
Date:	Sat, 22 Jul 2023 18:33:31 +0100
Message-ID:	<CA+kUOa=PaUHpv6cyJnwab_cRxZz9+b+=P-vkzUtnk7SSvXce2g@mail.gmail.com>
Subject:	Re: Most git executables are hard links to git.exe?
To:	jhg AT acm DOT org
Cc:	cygwin AT cygwin DOT com, Jim Garrison <jhg AT jhmg DOT net>
X-Spam-Status:	No, score=-0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,
	SPF_PASS, TXREP,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Adam Dinwoodie via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Adam Dinwoodie <adam AT dinwoodie DOT org>
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 36MHY5IG009096

On Fri, 21 Jul 2023 at 22:54, Jim Garrison via Cygwin wrote:
>
> On 07/21/23 14:52, Brian Inglis wrote:
> > On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
> >> Git comes with over 100 executables, mostly in /usr/libexec/git-core,
> >> that all appear to be *hard* links to /bin/git, in both Cygwin and
> >> Windows. The Windows fsutil command shows they're all hard linked:
> [snip]
> >> I'm curious to know if there's a specific reason for this implementation
> >> that would make it the choice over symbolic links.
> >
> > For the same reason you are complaining about backups not taking
> > hardlinks into account: to avoid distributing 400MB instead of 3MB.
> >
> > Cygwin backup utilities should be able to deal with these e.g. rsync -H,
> > --hard-links, although it appears xcopy and robocopy may not under
> > Windows 10; don't know about other utilities or Windows 11.
>
> But why not use symbolic links to accomplish the same thing?

A few reasons off the top of my head:

- This is what the Git build tooling does out of the box. Minimising
the number of changes we're making as a downstream packager makes my
life easier as package maintainer.

- This is what happens on *nix systems, and Cygwin generally
prioritises matching function with *nix systems over interoperability
with Windows tools; if you want interoperability with Windows tools,
you might be better off with Git for Windows. That's not trying to
brush you off; the reason Cygwin Git and Git for Windows both exist is
that they're both serving different user needs.

- As others have said, Windows in general has good support for
hardlinks, while it has no inherent support for Cygwin's symlinks.
That means a Windows application would need to be aware of Cygwin to
have any chance of usefully interacting with those files if they were
symlinks, whereas a Windows application doesn't need to be aware of
Cygwin at all to be able to handle hardlinks, it only needs to know
how to handle hardlinks on Windows.

- Although I've not measured it, I expect there's a small runtime cost
from using symlinks over hardlinks. Cygwin's Git is already slow, for
a variety of difficult-to-solve reasons, and I'm reluctant to do
anything that might make that worse.

- Inertia. The current situation works well for most people, and
changing things takes effort and risks breaking other folks' use
cases.

I do acknowledge that while many Windows tools *could* handle
hardlinks, many don't. I'm not at all surprised that some backup
utilities don't handle them well and back up each file separately. I
think switching to using symlinks for Cygwin's executables is the
wrong solution, though.

Instead, I'd suggest (a) finding a backup tool that can handle
hardlinks, (b) finding a backup tool that uses compression so the
"duplicate" data gets deduplicated as part of the backup process, (c)
not backing up most of Cygwin's /usr directory in the first place – in
most cases I wouldn't expect there to be anything in that folder that
couldn't be readily recovered elsewhere anyway – or (d) switching to a
disk imaging backup system rather than a file-based one if it's really
important that you have everything on disk ready to restore.

Hopefully that's all useful and/or interesting, even if it's not the
answer you were hoping for!

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -