Has anyone ever seen a plugin company distribute plugins via .dmg that has symlinks to /Library/Audio/Plug-Ins/Components where dragging into the folder actually works?
I’ve tried every trick in the book (different dmg formats, different tools, named/unnamed symlinks, permissions, signed/unsigned, DS_Store present/removed), but on a machine that didn’t make the dmg, symlinks won’t let you drop files into them.
It works if you created the dmg and it works to double click to open the folders. It also works magically for /Applications but I don’t see any extended attributes or other trick that the OS might be using…
Note that ~/Library isn’t an option, as the ~ is resolved at the time the symlink is made so it would be a symlink to /Users/sudara.
I thought dmg would be a nice n’ easy distribution route on macOS (almost preferable to a heavier duty installer) but this degrades the UX… The workaround would be to have the background image specify “Step 1: Double click folder to open, Step 2: drag plugin into opened window (not the folder icon)”
There has to be a reason it works with /Applications but not with /Library/Audio/Plug-Ins/*…
I think this technique is being deprecated by Apple (because: sandbox) and the preferred method to do the installs from now on is with a .pkg-type installer. From what I can gather, Apple want to move away from .dmg installers …
But, besides that - when you create the link, are you using the ‘-s’ option, to ensure that a ‘symbolic link’ is made - otherwise it’ll make a hard link, which won’t work (because everyones’ inodes differ)?
e.g.
$ cd /Volumes/MyNewDiskImage && ln -s /Library/Audio/Plug-Ins/Components ./Components
Yup! Neither symbolic links nor macOS aliases created from finder (which can differ) nor “relative symlinks” (which is something osxtools can create, linking to ~/Library) worked. Apple definitely wants everyone on the App store, but .dmg seems alive and supported (the shiny new notarytool supports it, etc). My theory is it’s just a niche issue and only /Applications has some exception in the actual Finder code. I used an Apple developer support incident on it, I’ll report back if they say anything interesting.
What leads you to that conclusion? I’m very much under the impression it’s the other way around! My impression is that Apple don’t like pkg style installers because they can run arbitrary scripts normally with admin privileges however, for the time being they have little choice but to support them.
I think what they would prefer is that things are installed via the AppStore, and apps themselves set up everything required when first launched. As I understand it with the latest drivers for example (which are now all user space), they are designed to be installed by an app on first launch.
Okay, this worked for me - @sudara, perhaps you’re not creating a HFS+ image?
$ ls -l TestContents
total 8
lrwxr-xr-x 1 aa_jv staff 34 Jul 11 15:15 Components -> /Library/Audio/Plug-Ins/Components
-rw-r--r-- 1 aa_jv staff 52 Jul 11 15:15 readme.txt
$ hdiutil create testImage.dmg -ov -volname "TestImage" -fs HFS+ -srcfolder "./TestContents"
$ open testImage.dmg
$ ls -l /Volumes/TestImage/Components/
total 0
drwxr-xr-x 3 root wheel 96 Sep 8 2020 Analog Lab 4.component
drwxr-xr-x 3 root wheel 96 Jan 28 20:59 Analog Lab V.component
drwxr-xr-x 3 root wheel 96 Feb 22 20:24 Chorus JUN-6.component
drwxr-xr-x 3 root wheel 96 Feb 22 20:47 Comp FET-76.component
drwxr-xr-x 3 root wheel 96 Feb 23 13:18 Delay TAPE-201.component
drwxr-xr-x 3 root wheel 96 Feb 22 21:02 Filter MINI.component
drwxr-xr-x 3 root wheel 96 Feb 23 11:53 Phaser BI-TRON.component
drwxr-xr-x 3 root wheel 96 Jan 27 21:15 Pigments.component
drwxr-xr-x 3 root wheel 96 Nov 23 2020 PolarDesigner.component
drwxr-xr-x 3 root wheel 96 Feb 22 21:17 Pre 1973.component
drwxr-xr-x 3 root wheel 96 Feb 22 21:19 Pre TridA.component
drwxr-xr-x 3 root wheel 96 Feb 22 21:36 Pre V76.component
drwxr-xr-x 3 root wheel 96 Feb 22 20:05 Rev PLATE-140.component
… transferred testImage.dmg to another Mac, different user, confirmed that I was able to access the /Library/Audio/Plug-Ins/Components subdirectory using a simple double-click, could put files in there easily (once authenticated) … (EDIT: no, I didn’t accidentally bundle the .component files into the .dmg volume, before you ask - the only thing the testImage.dmg volume contained was the symbolic link to the directory…)
… I concur with your assessment: Apple want Apps themselves to do the bundling/installing … the old .dmg method is not going away, but I think - with the changes to AUV3 - Apple are definitely signalling that they want .app bundles to be the solution for everything … could be wrong, just imho.
Hey, I really appreciate you trying to reproduce this, Jay! Awesome.
It’s drag-n-drop to the dmg symlink that I can’t get to work (see the gif in the OP) — it works to double click the symlink to open the folder and drop in.
Drag and drop (to the symlink icon in the dmg, not the double-clicked-and-opened-folder) on the computer that didn’t create the dmg? If that’s the case would you mind sending me the dmg so I can inspect it? It’s true, I never explicitly tried -fs HFS+, I’ll give that a whirl.
I tested this by dragging the readme.txt file that I included in the .dmg Volume, directly onto the Folder symlink named “Components”, so I don’t think that’s quite an accurate assessment, yet …
BTW, ‘man hdiutil’ is your friend - seems it might be related to the filesystem type of your test machine:
PERMISSIONS VS. OWNERS
Some filesystems support permissions including users and groups. While important for security on a managed filesystem, users and groups ("owners") pose challenges for unmanaged, shared filesystems such as
those typically present in disk images. macOS's solution to this problem is to make owners optional, both while creating files and enforcing permissions.
By default, unknown HFS+ filesystems on "external" devices (including disk images) mount with their owners ignored (mount -o noowners). Normally when owners are ignored, the system uses a special _unknown
user and group to dynamically substitute the current user's identity for any owners recorded in the filesystem. These _unknown owners are even written to the volume when creating new files. The new files
will continue to have "floating" ownership when mounted with owners honored. The net result is that shared volumes behave as expected regardless of how they are accessed.
The behavior is different when disk images are attached. With disk images, the owner of all files in a filesystem mount for which owners are ignored is the user attaching the disk image. The attaching owner
is also used when creating new files.
On modern macOS systems, root (UID 0) can "see through" the "owners ignored" user mappings. Thus
sudo ls -l /Volumes/imageVol
will show whatever is really stored in the filesystem (possibly _unknown) regardless of whether owners are currently being honored on that volume. In contrast, non-root users will see themselves any time
_unknown is in effect, whether the default for the mount when owners are ignored or because _unknown is stored on disk. For disk images, non-root users will see owners matching the user that attached the disk
image.
Unlike owners, permissions are never optional. A non-writable file will not be writable just because owners are ignored. However, a file that is writable by its owner will be writable by everyone if _unknown
is the effective owner of the file for that file. Because anyone accessing an owners-ignored file is treated as the owner, everyone is effectively the owner. Because the default behavior for disk image
filesystems is for all files to be owned by the user attaching the disk image, other users will be treated per the 'group' (if applicable) and 'other' permission modes.
diskutil(8)'s enableOwnership or the Finder's Get Info window can be used to configure a system to respect the on-disk owners for a filesystem in the future.
Okay - a weird finding. If I DOWNLOAD the .dmg file, somehow MacOS notices and doesn’t let me drag the included readme.txt file into the Components symlink - reproducing your circumstances.
If I merely copy the .dmg file (USB Stick) to another Mac - i.e. it was not Downloaded, rather just copied with the Finder - then I can copy the readme.txt file into the Components symlink.
Try this - make your own .dmg with the commands listed above, then try the test. Then, use the one I attached to this forum (download it) and notice the difference.
Yeah, I chased down the quarantine stuff a bit already (been at this for a day or so). The macOS dmg here is notarized but still fails. I’ve tried explicitly signing the dmg (which shouldn’t be necessary) and different combos of code signing and notarization.
The last thing I was investigating yesterday was the more obscure extended attributes I was seeing, such as com.apple.macl stuff — something something registering user intent.
. Example dmg with the issue is here: Make /Library/Audio folders writable · sudara/pamplejuce@8765dc4 · GitHub