From: Andrey Repin <anrdaemon@yandex.ru>
To: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>, cygwin@cygwin.com
Subject: Re: RFE: find <path> -d -size 0 => doesn't find empty directories
Date: Fri, 02 Nov 2018 14:05:00 -0000 [thread overview]
Message-ID: <166676694.20181102170241@yandex.ru> (raw)
In-Reply-To: <787c5490-d4a8-46e1-20d6-e7fc9a1f5db8@SystematicSw.ab.ca>
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
prev parent reply other threads:[~2018-11-02 14:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 23:02 L A Walsh
2018-11-01 0:02 ` Norton Allen
2018-11-01 1:16 ` Mark Geisert
2018-11-01 4:40 ` Mark Geisert
2018-11-01 16:27 ` (SOLVED) " L A Walsh
2018-11-02 5:33 ` Mark Geisert
2018-11-01 16:20 ` Andrey Repin
2018-11-02 5:05 ` Brian Inglis
2018-11-02 14:05 ` Andrey Repin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=166676694.20181102170241@yandex.ru \
--to=anrdaemon@yandex.ru \
--cc=Brian.Inglis@SystematicSw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).