Re: chattr makes cygport slow
Jon Turney via Cygwin-apps writes:
> So, the idea here is that we try to ensure it's on, at least for the
> working directory.
That IMHO should only be done when the working directory is created, but
not retroactively applied to an existing workdir.
> 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.
Meanwhile I've done this:
--8<---cut here---start->8---
if [ $OSTYPE = "cygwin" ]
then
+ [ -n "$(find ${workdir} -maxdepth 0 -empty)" ] &&
chattr -fR +C ${workdir} >/dev/null 2>&1 || true
fi
--8<---cut here---end--->8---
I think it should be moved into a function that can be called before the
prep command, but I haven't actually tried it for a longer time or
checked what tests need changing due to the extra output:
--8<---cut here---start->8---
>From 4be00357be8cb14493413b7c8c80777671c21e5d Mon Sep 17 00:00:00 2001
Subject: [PATCH] cygport.in: move case-sensitivity testing / enabling into
functions
---
bin/cygport.in | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/bin/cygport.in b/bin/cygport.in
index 02e9b7bf..a6dabc91 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -577,25 +577,36 @@ declare -r pkg_count=${#pkg_name[*]};
# this requires workdir to be already defined
mkdir -p ${workdir}
-if [ $OSTYPE = "cygwin" ]
-then
- chattr -fR +C ${workdir} >/dev/null 2>&1 || true
-fi
-
-rm -f ${workdir}/.probe_case_sensitivity
-touch ${workdir}/.PROBE_CASE_SENSITIVITY
-probe=$( [ -f ${workdir}/.probe_case_sensitivity ] && echo "failed" || echo ""
)
-rm -f ${workdir}/.PROBE_CASE_SENSITIVITY
-if [ -n "$probe" ]
-then
+__enable_case_sensitivity() {
+inform "Trying to enable case sensitivity on ${workdir}"
+if [ $OSTYPE = "cygwin" ]
+then
+ [ -n "$(find ${workdir} -maxdepth 0 -empty)" ] &&
+ chattr -fR +C ${workdir} >/dev/null 2>&1 || true
+ __probe_case_sensitivity
+fi
+}
+
+__probe_case_sensitivity() {
+mkdir -p ${workdir}
+rm -f ${workdir}/.probe_case_sensitivity
+touch ${workdir}/.PROBE_CASE_SENSITIVITY
+local probe=$( [ -f ${workdir}/.probe_case_sensitivity ] && echo "failed"
|| echo "" )
+rm -f ${workdir}/.PROBE_CASE_SENSITIVITY
+if [ -n "$probe" ]
+then
if defined _CYGPORT_RESTRICT_case_insensitive_
then
- error "Package ${NAME} cannot be built on a case-insensitive
filesystem";
+ error "Package ${NAME} cannot be built on a case-insensitive
filesystem";
else
- warning "Building on a case-insensitive filesystem";
+ warning "Building on a case-insensitive filesystem";
fi
-fi
-unset probe
+ false
+else
+ inform "Building on a case-sensitive filesystem";
+ true
+fi
+}
# this requires S and B to be already defined
if ! defined _CYGPORT_RESTRICT_debuginfo_
@@ -638,15 +649,18 @@ while (( arg_n < argc ))
do
case ${argv[${arg_n}]} in
downloadall|fetchall|wgetall|getall)
+ __probe_case_sensitivity || __enable_case_sensitivity;
__src_fetch;
_status=$?;
;;
download|fetch|wget|get)
+ __probe_case_sensitivity || __enable_case_sensitivity;
__DL_ONLY_MISSING=1 __src_fetch;
_status=$?;
;;
prepare|unpack|prep)
- __stage Preparing;
+ __probe_case_sensitivity || __enable_case_sensitivity;
+ __stage Preparing;
__src_prep;
_status=$?;
;;
--
2.41.0
--8<---cut here---end--->8---
> I think there's possibly something else going wrong if it's taking 5
> minutes, as that seems excessive.
Try it on the gcc build dir…
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: chattr makes cygport slow
> 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.
Thanks. Annoying, I realize. Unfortunately doing it separately for each command
isn't right either, if it runs 3 times instead of once when I run 'cygport prep
make inst'.
Also, just fixing it for 'finish' would still leave the delay for the other
commands. Maybe a switch that would allow turning it off, either host-wide in
~/.cygport.conf, or for a project that didn't need it in *.cygport.
> I think there's possibly something else going wrong if it's taking 5
> minutes, as that seems excessive.
Could be BLODA. My host has MS antivirus.
Re: chattr makes cygport slow
On 06/07/2023 17:18, Brian Inglis via Cygwin-apps wrote:
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?
I believe that might have been the case in some previews, but it does
inherit now. Otherwise it's almost completely, unusably useless.
Re: chattr makes cygport slow
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.
