This is the mail archive of the 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]

ls slowdown in latest cygwin on my system

Hello Cygwineers,

Last November, when I upgraded to cygwin 1.3.13, I noticed ls.exe delaying its output for several seconds before starting to print.
I didn't have a copy of my cygwin version before 1.13.13 so I couldn't reproduce a test case (with cygcheck and strace output)
demonstrating that ls -l worked fine before 1.3.13.    However, I'll try very hard to look into my old CDs to check if I still have
my very first cygwin (where ls -l worked normally).

1) The behaviour of ls -l in cygwin 1.3.13 *in my system* does not matter when CYGWIN=ntsec or CYGWIN=nontsec.
2) It doesn't matter too whether I repeat the operation several times (in the hope that the results will be cached).
3) Invoking ls -l under under /cygdrive/c/winnt/system32/ (where there are around 2000++ files) takes around 10 to 35 seconds before
the files are printed as output.   There is a delay before the string "total <some_number>" is printed and soon after it is printed.
The delay after "total <some_number>" gets printed until ls starts its listing takes much longer than the delay before it
"total <some_number> gets printed.

I tried to revert to the old version of cygwin which I had (1.3.12-4) in the hope that ls would work normally.  Still it did not.  I
attached the output of strace using cygwin dll version 1.3.12-4

Today, I upgraded the cygwin dll through setup and got the latest version.  Still, there is no improvement in the behaviour of ls
when invoked as ls -l.  (I've attached the output of "cygcheck -svr" and "strace ls -l").

I attached the output of strace as well (with the latest version of cygwin installed).

I also attached the output of cygcheck run from the latest version of the cygwin1.dll

(All the above  I've installed through setup.)

The output of strace shows that ls tries to open the file /usr/local/etc/zoneinfo/posixrules but it does not exist.  Neither does
/usr/local/etc/zoneinfo/ exist in the system.  When strace reaches the point where ls starts opening the non-existent file, that's
where the delay begins.  There is no output from strace at the time of the delay.  So cgf was probably right in his response last
November (see when he mentioned that there're some things that are not being

I haven't seen any similar posts regarding this issue (i.e. ls -l slowing down) in the mailing list for the past several months so I
guess that this problem is unique to my setup (or system).

If there's anything you'd want to know about my setup, I'd be very glad to point it out.
I'm not sure if these info are relevant but I'll include it here anyway.

1) the system is configured for japanese support (i.e. i could type and read japanese text)
2) cygwin is installed in an ntfs file system
3) /usr/local/etc/zoneinfo does not exists but ls (as shown by strace) keeps looking for the file posixrules under it.
4) there are no network drives mounted on the system
5) there are no cygwin background processeses that run in the system.
6) upon observing windows task manager, every time ls -l is invoked, the program lsass.exe begins to take as much as 60% of
cpu time.

Thanks a lot!

Best Regards,

Carlo Florendo
Astra Philippines, Inc.

Attachment: strace-1.3.22-1.txt.bz2
Description: Binary data

Attachment: strace-1.3.12-4.txt.bz2
Description: Binary data

Attachment: cygcheck.txt.bz2
Description: Binary data

Unsubscribe info:
Problem reports:

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