X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=LOFGr3Z0vK3fmSXo
	rFWUUCNwNjkU2E3EiZws4xos/4lm6seiyacvQO8/VvrVGZb/W5F2VOWh/MFsxS5h
	LglOwjFl7anKdWRGl7dKHf2YEaK2W0IhM5a6aFCEv1mywZ9IO6Ek9WJQm9Cvm7mR
	Fg3S0lng4NB7D68d8z5oCM3Viqo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=ZxGpvxvvNAqUa22QCHyU7l
	2x8S8=; b=ylmpb20HnXpdo9aDciCt7bZW+T8Ys4/eSZWUT4hx9HF4erSluYtuSv
	8LhFK0blYbWt4XOvaygPVykc4Mvo0LynYTqOs45do7CvOyxaDVSnQ81uTJqsDqJP
	HmcWvUdmDnrRFMhGD6JXlwBhjwMU3+ljASSb0eUweH977vaisps9k=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=2.0 required=5.0 tests=BAYES_50,FREEMAIL_FROM,KAM_THEBAT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 spammy=vote, H*UA:Bat!, inglis, Inglis
X-HELO: forward105o.mail.yandex.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1541167503;	bh=W57Q7r893nzKdJZacG23y/kzDZElbMF/kpu6O4Tq9MU=;	h=Date:From:Reply-To:Message-ID:To:Subject:In-Reply-To:References;	b=vBhzz+CTdF5jpnHnK1QMEmQnQeDamcN8PHwEVpUQiABHxAcP8VX7EO/7UXCLjvrwX	 ZZyAiUktxEkxQIkmdFPm8zcyYIbsozHVgX0LMCfPPa/AkcgLcnXUFtL48TogcPkycT	 rjFh2YhGVUiOQhm3223LNiG6ATBjLZE6pkczJbVs=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1541167502;	bh=W57Q7r893nzKdJZacG23y/kzDZElbMF/kpu6O4Tq9MU=;	h=Date:From:Reply-To:Message-ID:To:Subject:In-Reply-To:References;	b=ZAeEVBzAIxzzfnGqFss6PVIKt/LWLuKOa5KL0jHU6ySHNGP6GUvhPx904uOt4D29z	 CwOqGDojXRIpCIK5FAdm1nS5V+UJEbw7djirYokgfs6Pp5DpoJagqjikJXNOUK8xjR	 f1ynIwt0D7ERizKzDoWYvc6LPf2D7P/XRCGQ2VPs=
Authentication-Results: smtp4j.mail.yandex.net; dkim=pass header.i=@yandex.ru
Date: Fri, 2 Nov 2018 17:02:41 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <166676694.20181102170241@yandex.ru>
To: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>, cygwin AT cygwin DOT com
Subject: Re: RFE: find <path> -d -size 0 => doesn't find empty directories
In-Reply-To: <787c5490-d4a8-46e1-20d6-e7fc9a1f5db8@SystematicSw.ab.ca>
References: <5BDA347D DOT 8070909 AT tlinx DOT org> <1792215646 DOT 20181101191249 AT yandex DOT ru>   <787c5490-d4a8-46e1-20d6-e7fc9a1f5db8 AT SystematicSw DOT ab DOT ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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