slow handling of large sets of files?

Reini Urban
Sun Feb 6 09:13:00 GMT 2005

Brian Dessent schrieb:
> 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.

Yes, that's the cause.
ls is a bit optimized compared to cmd.exe dir for large filesets, but 
checking ACL's are the real pain.

nontsec or remove all the cygwin created groups but one. cygwin insists 
on at least two groups. Windows is happy with one.

Either turn off ACL inheritance (best) or if so be sure the the 
inherited ACL has not too much groups.

Compare getfacl . to CACLS . and you'll see the difference.
Reini Urban

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list