public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: cygwin-apps@cygwin.com
Subject: Re: chattr makes cygport slow
Date: Thu, 6 Jul 2023 10:18:35 -0600	[thread overview]
Message-ID: <6eade186-d946-c32f-83c8-57c68d0f9126@Shaw.ca> (raw)
In-Reply-To: <3gbdai9h69p2c67lv8g7f873hje9skmglq@4ax.com>

On 2023-07-06 06:19, 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.

The attribute does not appear to be inheritable, so will not be applied to 
subdirectories created by make, or in cygport xargs commands, unless supported 
in cygwin1.dll, perhaps why it is open coded in cygport?

Perhaps it could be moved below case prep, into src_prep `__mkdirs`, or globally 
define `mkdir_p()` which applies it to each directory in those paths?
Could this also be defined in MKDIR_P for make or are those limited to binaries?

All cygport scripts appear to consistently use `mkdir -p` including after `xargs 
-r` (`--no-run-if-empty`) except:

/usr/share/cygport/cygclass/fossil.cygclass:    mkdir ${FOSSIL_MODULE}

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

  reply	other threads:[~2023-07-06 16:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06 12:19 Andrew Schulman
2023-07-06 16:18 ` Brian Inglis [this message]
2023-07-08 12:19   ` Jon Turney
2023-07-06 17:36 ` Andrew Schulman
2023-07-08 12:16   ` Jon Turney
2023-07-08 13:23     ` Andrew Schulman
2023-07-08 14:22     ` ASSI
2023-07-16 16:15       ` Jon Turney
2023-07-16 19:32         ` ASSI
2023-07-23 15:33           ` Jon Turney
2023-07-23 19:13             ` ASSI
2023-07-24 21:07               ` Jon Turney
2023-07-28 11:35             ` Andrew Schulman

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=6eade186-d946-c32f-83c8-57c68d0f9126@Shaw.ca \
    --to=brian.inglis@shaw.ca \
    --cc=cygwin-apps@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).