Comments: Authenticated sender is From: "Alaric B. Williams" To: Lorier Date: Sat, 26 Apr 1997 21:45:22 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Usage of directory entries Reply-to: alaric AT abwillms DOT demon DOT co DOT uk CC: pierre AT tycho DOT com, "Alaric B. Williams" , Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com In-reply-to: Message-ID: <862087322.067830.0@abwillms.demon.co.uk> Precedence: bulk On 26 Apr 97 at 23:58, Lorier wrote: > >You mean /more easily done/. > Better: You don't have to "lock" files, you don't have race conditions and > hundres of other problems... There is far more that can go wrong if your > defragging AND allowing write access... One possible solution is to defrag by rebuilding a copy of the file in a linear region somewhere, then switching from the old copy to the new one. While a file is being shifted, block read requests come from the old version, and block write requests go to the new version, leaving a note to the copier not to copy the old version of that block from the original contorted file! The background defrag need not be a perfect defragger. If we can just show that it will defragment most files without screwing anything up, then we can leave it chuntering away. A full scale bring-the-system-down defrag tool will only then be needed if empirical evidence shows that the background one isn't good enough! > Adding up a CRC of something that > changes 1/2 way through is going to make things go BANG I think :) Now, how would that arise???? > > Better for users if it happens invisibly. > Umm... Semi-invisibly :) Give the "power users" power to do what they NEED. :) Yes, I'd agree with that. Invisible in general use, but /findable/ if you wanna see it! ABW -- Alaric B. Williams (alaric AT abwillms DOT demon DOT co DOT uk) ---<## OpenDOS FAQ ##>--- Plain HTML: http://www.delorie.com/opendos/faq/ http://www.deltasoft.com/faq.html Fancy HTML: http://www.deltasoft.com/faq0000.html