Message-Id: <200005231623.MAA17711@delorie.com>
Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: "Parker, Ron" <rdparker AT butlermfg DOT com>
To: "'cygwin-developers AT sourceware DOT cygnus DOT com'"
	 <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: RE: setup: built-in tar
Date: Tue, 23 May 2000 11:23:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

> This first step removes tar and gzip, replacing them with zlib and a
> built-in tar.

I am sure you are aware of this, but part of the reason for using the actual
tar.exe was because it was a cygwin program and automatically dealt with
soft links, hard links and mounts properly for the current OS/FS
combination.  This was without requiring setup to contain logic that already
existed in cygwin.  A cursory examination of tar.c shows that at least hard
links are changed into file copies even when running on NTFS which does
support real hard links in cygwin.

One of the reasons for all of the cygwin utilities, gzip, tar, mount, etc.
in setup was so that we could just rely on everything working the way it
would be done by cygwin.  This was instead of risking leaving out some
standard part of cygwin functionality.  Are we taking into account text vs
binary mounts, binmode vs nobinmode, ntea vs nontea, ntsec vs nontsec, FAT
vs NTFS, etc?  There are a lot of issues if we set about implementing our
own internal version of tar.

That said I personally cannot think of a reason that would prevent us from
using the internal implementation of gzip, except for the fact that it might
increase the drive space that is used for an installation.  Currently I
believe "tar -z" uses pipes to pass data from gzip to itself and if we
gunzip the tar ourself and pass that off to tar, it would likely be
decompressed to the hard drive as an intermediate step.  I don't consider
this to be a big issue.

> This built-in tar also allows setup to more closely
> control where files are going; it can ignore conflicting mounts the
> user has set up in favor of what it knows is right, for example.

If I may be so bold, who are we to say what is "right".  God knows I am not
a relativist, but if a person has gone to the effort to setup specific
mounts for their specific needs, who are we to say they are wrong?  Of
course this in just IMHO.

Is there an actual problem here that you are trying to address or is it to
simplify the tar-like code?  I am just wondering about the motivation.