This is the mail archive of the
mailing list for the Cygwin project.
Re: Performance of "ls -F"
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin at cygwin dot com
- Date: Fri, 22 Jan 2016 22:04:13 +0100
- Subject: Re: Performance of "ls -F"
- Authentication-results: sourceware.org; auth=none
- References: <loom dot 20160121T163405-489 at post dot gmane dot org> <CAH5rLZVWiGz2n-3Ru-C0_5KU-Cc4NipJPn1NQVphN2UetUK4iA at mail dot gmail dot com> <3a9ff6ec2d5e4e64a96a8f8e31d12f22 at ntmaexbe04 dot bedford dot progress dot com> <loom dot 20160122T082744-501 at post dot gmane dot org> <20160122201418 dot GC3268 at calimero dot vinschen dot de>
Corinna Vinschen writes:
> Just a hint: ls -F requires to stat every single file. stat in turn
> requires to load not only the usual metadata but also to fetch the ACL
> and convert it to POSIX permissions.
The timings are from shares mounted with the noacl option, so that bit
of code shouldn't be involved. I will try the same operations on an ACL
enabled mount of the same share later and I also need to find a share
that is exported from a true NTFS server for comparison.
> Assuming this slow access only occurs under 2.4.0,
No, the behaviour is quite a bit older, although I didn't time it since
I didn't recognize the connection to the aliased ls. In any case, it
really is just the determination of whether or not the file is
executable that takes up all that time.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple