From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-047.btinternet.com (mailomta5-sa.btinternet.com [213.120.69.11]) by sourceware.org (Postfix) with ESMTPS id E93E03858D39 for ; Sat, 8 Jul 2023 12:16:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E93E03858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-003.btmx-prd.synchronoss.net ([10.2.38.6]) by sa-prd-fep-047.btinternet.com with ESMTP id <20230708121623.CLJL9056.sa-prd-fep-047.btinternet.com@sa-prd-rgout-003.btmx-prd.synchronoss.net>; Sat, 8 Jul 2023 13:16:23 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 64067FEB0E54DEC6 X-Originating-IP: [81.129.146.180] X-OWM-Source-IP: 81.129.146.180 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedviedrvdefgdehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepiefhfeetgeekffdvgfelkeeujeevleeuledvhedvtdehleejkeeggeelkefhtdfgnecuffhomhgrihhnpegthhgrthhtrhdrihhnnecukfhppeekuddruddvledrudegiedrudektdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduvdelrddugeeirddukedtpdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopegthihgfihinhdqrghpphhssegthihgfihinhdrtghomhdprhgtphhtthhopehstghhuhhlmhgrnhdrrghnughrvgifsegvphgrrdhgohhvpdhrvghvkffrpehhohhsthekuddquddvledqudegiedqudektddrrhgrnhhgvgekuddquddvledrsghttggvnhhtrhgrlhhplhhushdrtghomhdprghuthhhpghushgvrhep jhhonhhtuhhrnhgvhiessghtihhnthgvrhhnvghtrdgtohhmpdhgvghokffrpefiuedpoffvtefjohhsthepshgrqdhprhguqdhrghhouhhtqddttdef X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.129.146.180) by sa-prd-rgout-003.btmx-prd.synchronoss.net (5.8.814) (authenticated as jonturney@btinternet.com) id 64067FEB0E54DEC6; Sat, 8 Jul 2023 13:16:23 +0100 Message-ID: <820bb54e-770e-5994-465a-476b88e74180@dronecode.org.uk> Date: Sat, 8 Jul 2023 13:16:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: chattr makes cygport slow Content-Language: en-GB To: "Schulman, Andrew" , "cygwin-apps@cygwin.com" References: <3gbdai9h69p2c67lv8g7f873hje9skmglq@4ax.com> <6oudaidfkn4d7fnharmh7u3f3ionrcrgl0@4ax.com> From: Jon Turney In-Reply-To: <6oudaidfkn4d7fnharmh7u3f3ionrcrgl0@4ax.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 06/07/2023 18:36, Andrew Schulman via Cygwin-apps wrote: >> Recently I noticed that `cygport finish` has become really slow on some of my >> package source trees. After I run for example >> >> cygport libargp.cygport finish >> >> it waits for about 5 minutes without any message to the console, before the >> first "Removing work directory" message appears. >> >> pstree shows that during this time cygport is waiting for chattr. In >> /usr/bin/cygport I see: >> >> if [ $OSTYPE = "cygwin" ] >> then >> chattr -fR +C ${workdir} >/dev/null 2>&1 || true >> fi >> >> which is trying to make the workdir case-sensitive. >> >> Whatever the advantages of that are, it can take a long time. Would it be >> possible to skip it at least in the case of "finish"? It seems silly to spend >> all that time fixing up a directory tree that we then turn around and remove >> with rm -rf. For a long time, we've just been assuming that anyone using cygport has case-sensitivity turned on somehow (as the build underling a cygport might assume that it's present, as is normal on a unix) So, the idea here is that we try to ensure it's on, at least for the working directory. Skipping it when 'finish' is used isn't right, because then 'finish all' wouldn't work as desired. But yeah, it seems that this is in the wrong place. I'll look into moving it. I think there's possibly something else going wrong if it's taking 5 minutes, as that seems excessive.