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
