X-Spam-Check-By: sourceware.org Message-ID: Date: Fri, 12 Jan 2007 09:24:24 -0500 From: "Lev Bishop" To: cygwin@cygwin.com Subject: Re: Snapshot speed on managing files In-Reply-To: <20070112102454.GA8311@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <62410.52144.qm@web25001.mail.ukl.yahoo.com> <20070112102454.GA8311@calimero.vinschen.de> Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On 1/12/07, Corinna Vinschen wrote: > To overcome this problem the file is moved to the recycle bin in > unlink(2), so that it disappears from it's original directory, > regardless whether it's still in use or not. I tried to do this as > quick as possible but there's obviously some room for optimization. Corinna, I'm sure you thought about this already, but I thought I'd check. Does this patch make sure to move the file to the recycle bin on the same filesystem as the original file? So that it is really a rename (fast), rather than a move (slow). Does it do something to limit the number of files in a single subdirectory of the recycle bin? (Might get slow once there are too many, especially on non-NTFS. If not, might this be the cause of the problem the OP is having?). Lev -- 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/