This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: slow handling of large sets of files?

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:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]