Mixxx seeking access permission form iTunes Media folder on every launch

[AlrightHector]

Bug Description

Each time I launch Mixxx 2.4 beta it is seeking access permission to the iTunes Media folder.It's not retaining permissions.

Version

2.4

OS

Mac OS 10.14.6

[fwcd]

Interesting, I didn't even know that we still supported macOS Mojave. Looks like 2.4 still supports macOS all the way back to Sierra (10.12).

That sounds a bit like #11552. Is "Full Disk Access" enabled for Mixxx in your settings?

[fwcd]

I'll go ahead and assume that

is the prompt you're seeing too? In that case it's probably not an issue with the iTunes integration and rather sandboxing trying to access your media folder.

[fwcd]

By the way, the 2.4 snapshot builds from the website are quite outdated and IIRC do not include #11936 yet.

Could you try e.g. this build? (scroll down and download macOS Intel DMG)

Edit: Actually those builds are unsigned and unsandboxed, so they might fix the issue for now, but not later in the released builds... I'll see if I can get a sandboxed build ready for you to test.

[AlrightHector]

Thanks, the message doesn't appear for this build.

…

On Wed, 18 Oct 2023 at 15:00, fwcd ***@***.***> wrote: By the way, the 2.4 snapshot builds from the website are quite outdated and IIRC do not include #11936 <#11936> yet. Could you try e.g. this build <https://github.com/mixxxdj/mixxx/actions/runs/6411366768>? (scroll down and download macOS Intel DMG) — Reply to this email directly, view it on GitHub <#12137 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCPKQ7XTC3KGVF6CUCWOUIDX77OIVAVCNFSM6AAAAAA6FORYR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRYGUZDOMZTG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[fwcd]

Yep, that build was unsandboxed and wouldn't have had the issue anyway, sorry...

Could you try the following build? https://github.com/mixxxdj/mixxx/actions/runs/6562071482

[AlrightHector]

This build has the same issue, requesting permission. I've tried granting full disc access, but the issue remains.

…

On Wed, 18 Oct 2023 at 16:51, fwcd ***@***.***> wrote: Yep, that build was unsandboxed and wouldn't have had the issue anyway, sorry... Could you try the following build? https://github.com/mixxxdj/mixxx/actions/runs/6562071482 — Reply to this email directly, view it on GitHub <#12137 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCPKQ7SMRTPTQMPR24QDGU3X773J7AVCNFSM6AAAAAA6FORYR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRYG43TSNJYGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[fwcd]

Hm, that's annoying. So I'll assume that #11552 isn't fixed after all...

[fwcd]

I think the issue was introduced by this PR a while back (cc @uklotzde):

• Remove TrackFile class #3761

If you have some time to spare and would like to dig into this, you could try building Mixxx before:

git clone https://github.com/mixxxdj/mixxx.git
cd mixxx
git fetch origin pull/12138/head
git checkout 9e974cdb && git cherry-pick 59168913 e9223294 cf8e5a44
source tools/macos_buildenv.sh setup
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDEBUG_ASSERTIONS_FATAL=ON -DMACOS_BUNDLE=ON -DHAVE_STD_REGEX=ON -B build
cmake --build build
cd build
cpack -G DragNDrop

and after that PR:

git clone https://github.com/mixxxdj/mixxx.git
cd mixxx
git fetch origin pull/12138/head
git checkout c9f52dc1 && git cherry-pick 59168913 e9223294 cf8e5a44
source tools/macos_buildenv.sh setup
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDEBUG_ASSERTIONS_FATAL=ON -DMACOS_BUNDLE=ON -DHAVE_STD_REGEX=ON -B build
cmake --build build
cd build
cpack -G DragNDrop

and check whether that confirms the suspicion, i.e. that only the second build has the issue. (The cherry-picks are #4774 and #12138, which are needed to enable app sandbox in unsigned builds)

I don't have an older Mac around unfortunately, so I can't test this right now.

[m0dB]

@fwcd I can test this on Monterey. Would that be helpful or does it only affect older versions of macOS?

[fwcd]

Sure, that would be helpful

[fwcd]

I can consistently reproduce this on another Sonoma machine today after upgrading Mixxx to the latest snapshot... even after deleting sandbox.cfg and after granting full disk access. I suspect a reason why I didn't encounter the issue on the other machine was that I kept my tracks in ~/Music (which might have special sandbox privileges?) instead of a different "non-standard" subfolder of home. I'll have to investigate (and/or bisect) once I find more time...

[fwcd]

Note that the warning seems to be bogus, Mixxx has no issues reading the tracks even when clicking cancel. Not sure if that could be since I am running an unsigned build, but in general I don't really understand how the sandbox works, since browsing the entire file system in the "Computer" section of the sidebar is not an issue either...

[fwcd]

2.3 doesn't have this issue and the older 2.4 alpha snapshots from 2021, specifically those before #3761, are (sadly) no longer hosted on https://downloads.mixxx.org. The newer 2.4 snapshots all have the issue.

[uklotzde]

A missing or lost sandbox argument should be easy to fix. But unfortunately that could only be done by someone who has access to macOS as their development platform.