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: <4200247C.6F51F5E@dessent.net> Date: Tue, 01 Feb 2005 16:53:16 -0800 From: Brian Dessent Organization: My own little world... MIME-Version: 1.0 To: Cygwin List Subject: Re: slow handling of large sets of files? References: <1107286130 DOT 3063 DOT 65 DOT camel AT slb163188094105 DOT sugar-land DOT nam DOT slb DOT com> <6 DOT 2 DOT 0 DOT 14 DOT 0 DOT 20050201144916 DOT 05a42210 AT pop DOT prospeed DOT net> <1107289362 DOT 3063 DOT 78 DOT camel AT slb163188094105 DOT sugar-land DOT nam DOT slb DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Ken Sheldon wrote: > Not only Cygwin apps incur this large performance penalty. Something > similar happens with the cmd.exe prompt command "DIR", with the windows > file explorer, or with IIS (FTP server). This only seems to happen in > the directory structures created by my CygWin scripts (using apps: tar, > wget, cp) If I had to take a wild guess I'd say that's because when a normal win32 app creates a file it usually inherits its ACL from the parent directory, and presumably NTFS is tuned for this in some way so that checking thousands of such files that all inherit ACLs is fast. However, when cygwin creates a file or dir it usually sets the permissions explicitly to match what you would expect on a POSIX system (i.e. 644 or 755.) Try creating your files/folders with "nontsec" set and see if the cygwin-created trees are as slow as native-created ones. Brian -- 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/