Greetings, Brian Inglis!
> On 2018-11-01 10:12, Andrey Repin wrote:
>> L A Walsh wrote:
>>> Unfortunately, due to directories really not being in the user
>>> disk data space, but in the MFT(zone) (I think), the size
>>> comes back as zero ('0') for directories.
>>> Would it be possible (if not problematic) for the cygwin
>>> emulation layer to return some non-zero value if the
>>> directory has actual entries in it (ignoring structural
>>> values like "." and "..")? Maybe return as 'size' either
>>> a dummy number proportional to #entries (like 10*#entries),
>>> or something like summing up actual number (+1) of characters
>>> in the file list?
>>> Would that be difficult to do, or add?
>> Having something to this extent would be useful in case of searching for
>> directories with too many files, for example.
>> I'd vote for something like (entries << 7), which is closer to an average
>> ext2
>> counter. No need to ignore anything.
> I believe readdir(3) overhead is already high, and adding extraneous lookups
> to
> add metadata which is not readily available under NTFS/exFAT would slow it
> even
> further.
> Do you really want readdir(3) or stat(3) to recurse to sum the entry sizes for
> each subdirectory?
If a number of directory entires is not readily available, nothing can be
done.
No recursion was intended.
> Some of us have some large messy directories more reminiscent of Unix systems
> than typical of Windows systems.
> $ time du -sh /tmp/
> 91M /tmp/
> real 0m5.125s
> user 0m0.125s
> sys 0m1.077s
> $ time du -sh /var/log/
> 496M /var/log/
> real 0m42.725s
> user 0m0.687s
> sys 0m9.139s
--
With best regards,
Andrey Repin
Friday, November 2, 2018 17:02:01
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
