Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <014c01c2fa8b$c4ce5590$9582883e@pomello> From: "Max Bowsher" To: "Alan Dobkin" , "Robert Collins" Cc: "Cygwin Mailing List" References: Subject: Re: setup.exe final pre-release.. Date: Fri, 4 Apr 2003 10:22:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Alan Dobkin wrote: > On 4 Apr 2003, Robert Collins wrote: > >> you should use apache or IIS to serve out the mirror and add >> it to your mirror selection creen in the custom URL field. >> >> Then, setup won't check the md5's of every package. > > This seems like an overly complex workaround just to preserve > the existing functionality. Horribly over-complex. > And, it has the side effect of > creating another cache on each client system and re-downloading > each package before it is installed. Yes, bad! > This negates one of the > main reasons why I set up the local mirror in the first place, > i.e. so I could maintain a single repository on a local server > and avoid having a bunch of local caches on each installation. > >> The reason setup checks all the md5's is to ensure that what >> it's discovered in the cache hasn't been corrupted. > > That makes sense, but then there should be a way to bypass > this check so it doesn't happen every time. Perhaps something > like a dirty/clean flag that filesystems use to prevent having > to do a fsck/chkdsk every time it's mounted. Setup could set > this flag in its cache to dirty every time it does a download > and then set it to clean every time the full MD5 scan is done. I would consider a simple post-download check to be sufficient. If files are being corrupted on a local drive, then the user has bigger problems than Cygwin not working properly. >> There was another thread on this in cygwin-apps. Max >> considers it a release blocker, I don't. Accordingly, >> I said I was happy to consider patches.... Yep, and I've just re-awakened this discussion over on cygwin-apps :-) Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/