X-Spam-Check-By: sourceware.org Message-ID: Date: Fri, 12 Jan 2007 09:24:24 -0500 From: "Lev Bishop" To: cygwin AT cygwin DOT 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 DOT 52144 DOT qm AT web25001 DOT mail DOT ukl DOT yahoo DOT com> <20070112102454 DOT GA8311 AT calimero DOT vinschen DOT de> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 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/