X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E2953846046
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1673703971;
	bh=t9BlEDDx4SY6QI5zPrwkRyG4dFs6k9G47NYSFGWMFDE=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=LtiNdws2JTlTr8JXCEQOnV/rzZXDPbHmquqks3XcwacvNvUMiNNecNPaqEn9KAWLE
	 OqdQYMkwnYXd/qRWzA8CQaetm7wpd7mK3/HkucqMIwcqpTWsWnBYgcgMs4XYvAYS/W
	 YnRdnJjlxUU5kKpbw7BlDsjHKu67ux+DJV/kqBO4=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BE9ED38493D6
Date: Sat, 14 Jan 2023 13:45:32 +0000
To: cygwin AT cygwin DOT com
Subject: Re: Question about slow access to file information
Message-ID: <20230114134532.cc23lqifxzrde253@lucy.dinwoodie.org>
References: <797a8935-e38b-0c0f-87d8-b8df1e9fd76f AT cs DOT umass DOT edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <797a8935-e38b-0c0f-87d8-b8df1e9fd76f@cs.umass.edu>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Adam Dinwoodie via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Adam Dinwoodie <adam AT dinwoodie DOT org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Sat, Jan 14, 2023 at 11:42:58AM +1100, Eliot Moss via Cygwin wrote:
> Dear Cygwin'ers -
> 
> I have a separate drive mounted this way:
> 
> d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
> 
> One thing I use it for is to store backup files.  These tend to be 2 Gb
> chunks, and there can be hundreds of them in the backup directory.  (The drive
> is 5Tb.)  The Windows Disk Management tool describes it as NTFS, Basic Data
> Partition.
> 
> Doing ls (for example) takes a very perceptible numbers of seconds (though
> whatever takes a long time seems to be cached, at least for a while, since a
> second ls soon after is fast).
> 
> Windows Explorer (for example) and CMD do not seem to suffer this delay.
> 
> Any notion as to what is happening and what I might do to ameliorate it?
> 
> If it matters, the drive is removable (an external WD MyPassport hard drive).

I *suspect* this will be an issue with `ls` querying some file
metadata that are relatively slow to get out of an NTFS system, to
provide a similar interface to native *nix systems, where Windows' tools
unsurprisigly care more about the sorts of file properties that Windows
filesystems are better optimised for.

Based on experience, you might find using `ls --color=never` to be
quicker: querying some of the properties that `ls` likes to use for
colouring the output seems to require a bunch of extra queries to the
filesystem.  Failing that, if you have control over the directory
layout, making the structure deeper with fewer objects in each directory
will probably help.

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple