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: <3EC93CF2.A03F5C81@ieee.org> Date: Mon, 19 May 2003 16:22:10 -0400 From: "Pierre A. Humblet" X-Accept-Language: en,pdf MIME-Version: 1.0 To: Max Bowsher CC: cygwin AT cygwin DOT com Subject: Re: SPARSE files considered harmful - please revert References: <028f01c31e38$0e428c30$78d96f83 AT pomello> <20030519200848 DOT GA246379 AT Worldnet> <02c101c31e3e$7ffdc910$78d96f83 AT pomello> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Max Bowsher wrote: > >> Based on the posted numbers, global use of sparse files is a bad idea. > Can > >> we conditionalize sparse files on a $CYGWIN option? (Or something else, I > >> don't mind, but the important thing is that it should not be on by > default.) > > > > Why not make in on by default *when it can help*, i.e. when the write() > > leaves holes? > > Does anyone know of any programs which write non-sparse files, but not > contiguously? If there are none, then this approach should be fine. There must be some... Cygwin would check that the holes are bigger than a minimum threshold. Thus such files would never be really short and the penalty for guessing wrong would never be large. > In any case, the $CYGWIN approach could be a valid temporary measure until > someone writes the heuristic code. The code change I have in mind is very simple (because it's similar to what is already done against a Win95 bug), so we might as well skip the intermediate step. However a patch against current cvs might conflict with bigger changes that Chris Faylor has already made in his sandbox. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/