[Slackbuilds-users] template find/chmod RFC

[Jeremy Hansen]

On Mon, Aug 3, 2026, 7:01 PM Jim via SlackBuilds-users <
slackbuilds-users at slackbuilds.org> wrote:

> On Mon, Aug  3, 2026 at 11:38 (-0700), Jeremy Hansen wrote:
>
> > On Mon, Aug 3, 2026, 8:47 AM Jim via SlackBuilds-users <
> > slackbuilds-users at slackbuilds.org> wrote:
>
> >> On Mon, Aug  3, 2026 at 14:31 (+0200), Franzen via SlackBuilds-users
> wrote:
>
> >>>> chmod -R u+w,go-w,a+rX-st .
>
> >>> Here is an explanation why my proposal might not be that good. It's 13
> >> years
> >>> old, maybe chmod has changed to the better:
> >>> https://unix.stackexchange.com/a/79874
>
> >> Since I already timed the other replacement options, here is that one as
> >> well (again, on qt6-6.8.3-x86_64-2_SBo.tgz, where    find . | wc -l
> >> outputs 18282, which is a lot of files and directories).
>
> >> $ time find .  ! -type l -a \( -perm /111 -a ! -perm 755 -a -exec chmod
> -f
> >> 755 {} + \) -o \( ! -perm /111 -a ! -perm 644 -a -exec chmod -f 644 {}
> + \)
> >> 0.03s user 0.06s system 99% cpu 0.086 total
>
> >> $ time find .  ! -type l -a \( -perm /111 -a -exec chmod -f 755 {} + \)
> -o
> >> \( ! -perm /111 -a -exec chmod -f 644 {} + \)
> >> 0.07s user 0.22s system 99% cpu 0.285 total
>
> >> $ time chmod -R u+w,go-w,a+rX-st .
> >> 0.03s user 0.21s system 99% cpu 0.244 total
>
> >> Certainly the one with ! -perm is the fastest.  Whether brevity is worth
> >> two tenths of a second or not is probably a personal opinion.
>
> > I'm not sure why you're seeing such a minimal amount of time with the
> > original command.
>
> Me neither (but see below).
>
> > That's always been a bottleneck when compiling SlackBuilds between the
> > visible extraction and the visible compilation. It just sits there on big
> > builds while find does its thing silently.
>
> I can't say I've noticed that, but often I let a SlackBuild chug away in
> one window and look at something else.  The next time I build something
> I'll have to see if thee is something weird about my tests today.
>
> > I just tested my Kodi SlackBuild by adding time in front of the find
> > command and that took:
>
> > real    0m15.603s
> > user    0m10.402s
> > sys     0m5.215s
>
> That seems very slow, especially in light of the machine you describe
> below.
>
> Astonishing, in fact.  Given that the find comes right after untarring and
> chowning, I would think that all of the directory structure should be
> cached in pages lounging around in your 64 GB memory, unless you have a
> bunch of VMs running which have been allocated 60 or 62 GB of your RAM.
>

I have no VMs and only 3 relatively small containers running. Only using
about 5GB total.

jbhansen at craven-moorhead:~/sbo-git/multimedia/kodi$ free -h
               total        used        free      shared  buff/cache
 available
Mem:            62Gi       4.8Gi       1.8Gi       112Mi        56Gi
57Gi
Swap:           15Gi       1.1Gi        14Gi

> The chmod was incredibly fast:
>
> > real    0m0.076s
> > user    0m0.003s
> > sys     0m0.073s
>
> > As was the new find:
>
> > real    0m0.079s
> > user    0m0.016s
> > sys     0m0.062s
>
> Did you run the old stinky find again just to see how it went on second
> try?
>

Just tried it again. Left the chmod initially and then commented that out
and uncommented the original find with time in front of it and reran the
SlackBuild. It resulted in similar times:

real    0m15.079s
user    0m9.920s
sys     0m5.185s

> The amount of files in the Kodi source is around 33% smaller compared to
> > your qt6 example:
>
> > jbhansen at craven-moorhead:~/sbo-git/multimedia/kodi$ find
> > /tmp/SBo/xbmc-21.3-Omega/ | wc -l
> > 11697
>
> > This is all done on a Ryzen 9 5950X with a 2TB Samsung 980 Pro NVMe and
> > 64GB of RAM.
>
> If I had a desktop I'd probably have major hardware jealousy at this
> point. :-)


I've definitely been lucky, but I tend to buy big and then wait a long time
before replacing. I'm hoping to get close to a decade with this set up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260803/0309dd5d/attachment.htm>