Add support for file aliases to Publisher in Mac OS

[Timtoon]

I have two versions of a Publisher 2.4.2 document, but am using mostly the same files for both. Rather than make two copies, I kept the directory of files for one version in one place and used the "Make alias" function in Mac OS to make aliases to the originals in the second. I try to reconnect the aliased files in the second doc but Publisher reads the 4KB file alias as if it's the original.

I want Publisher to respect the symlink and point to the actual file, choke on reading the alias.

[loukash]

10 hours ago, Timtoon said:

I want Publisher to respect the symlink and point to the actual file, choke on reading the alias.

All Affinity apps support both aliases and symlinks as expected.
So either the alias or the PNG itself are broken.

Also note that "alias" ≠ "symlink". 

• If you're actually using symlinks (I do in certain scenarios), then you must not ever move the original file because a symlink is essentially just a POSIX file path/URL. Much like web URLs, if you change only one character in the original file's path, the symlink will break.
• Whereas an alias can "track down" the original file even if you move it to a different location on the same disk because it keeps track of its filesystem ID instead.

[walt.farrell]

1 hour ago, loukash said:

Also note that "alias" ≠ "symlink". 

From your description, it seems like the difference between what Windows would call symlinks and hard links.

[garrettm30]

3 hours ago, walt.farrell said:

From your description, it seems like the difference between what Windows would call symlinks and hard links.

I don’t know much about how symlinks and hard links are used in Windows. I have always understood (perhaps not entirely accurately?) that Mac aliases are the analog to shortcuts in Windows. Macs support both symlinks and hard links, which operate at the Unix level, as well as aliases, which work higher up at the Finder level and so come with conveniences but do not always work as expected for some, usually the more “techie,” purposes.

This is definitely a tangent, so I’ll leave it here, but if anyone is curious, there are various articles explaining the difference among aliases, symlinks, and hard links on Mac, such as this:

https://www.lifewire.com/aliases-symbolic-links-hard-links-mac-2260189

[Timtoon]

6 hours ago, loukash said:

All Affinity apps support both aliases and symlinks as expected.
So either the alias or the PNG itself are broken.

Were that the case, I wouldn't have filed the bug. The original images are not broken; they're the same ones I was using before. The aliases aren't broken because the originals they point to are still there.

Try this and see what you get:

1. Create Publisher doc1.afpub and a directory of images at `images1/`
2. Duplicate doc1.afpub to doc2.afpub
3. Duplicate the `images1/` directory and its contents for doc2.afpub and name it `images2/`
4. Open doc2.afpub and in the Resource Manager, update the image directory to `images2/`. It should all still work.
5. In the Finder, delete the contents of `images2/` and replace them with an alias to each file in `images1/`. These are aliases to the fundamentally identical image.
6. Open doc2.afpub and Update the Modified images
7. Error "Failed to open file"

[Timtoon]

aliases, yes. That's what I get for using a synonym

[Hangman]

17 hours ago, Timtoon said:

I want Publisher to respect the symlink and point to the actual file, choke on reading the alias.

How have you created your symlinks? If using Terminal then to create a symlink of your Downloads folder on your Desktop you'd use...

ln -s /Users/username/Downloads /Users/username/Desktop

Changing the source and destination folders as appropriate...

To make it easier just drag and drop the respective folders in the Terminal to ensure the correct file paths...

[loukash]

8 minutes ago, Timtoon said:

In the Finder, delete the contents of `images2/` and replace them with an alias to each file in `images1/`. These are aliases to the fundamentally identical image.

So, for the fun of it, I tried this scenario not just in APu, but also in InDesign CS5.5.
Guess what: ID suffers from the same "bug"!

Thing is, you can do a lot with aliases (or symbolic links for that matter), but there are limits. 

So, to fix this limit in APU, you may want to relink each placed image to the alias. 

Or even easier:
Don't duplicate the "images2" folder in the first place. You can link to the same external files in "images1" from multiple layout documents.

[loukash]

1 minute ago, loukash said:

You can link to the same external files in "images1" from multiple layout documents.

Or create an alias of the whole folder "images1" and place it to your new layout version.
That's the workflow I've been using since at least 25 years, going back to the QXP days…

[Timtoon]

3 minutes ago, loukash said:

Or create an alias of the whole folder "images1" and place it to your new layout version.
That's the workflow I've been using since at least 25 years, going back to the QXP days…

That doesn't solve the problem, either. I am trying two different versions where many of the images are the same, but not all. Here I thought an alias to the original file would be treated as the original, but that is definitely a limitation in Publisher.

As for relinking each image, this is exactly the kind of duplication of work I was hoping Publisher would help me avoid, but it either it's a bug or some other deficiency in the software. Kind of defeats the purpose of using aliases at all!

[loukash]

14 hours ago, Timtoon said:

that is definitely a limitation in Publisher.

As noted, that is a "limitation" of e.g. InDesign as well:
The layout app expects to find an image file at the saved location (which by itself is already a kind of "alias concept") to replace the saved low-res preview with the original image data on the fly. But instead it finds a file of the same name that doesn't contain any image data whatsoever. For a layout app, that is a "corrupt file". Therefore the asset must be relinked to the alias so that the layout app is now told by Finder where the original is stored.

It's a limitation of the Finder alias feature.

Some apps can't handle Mac aliases at all but may work with Unix symbolic links instead. Other apps have it vice versa. I've been doing lots of alias/symlink trickery in the past decades, and often it's been a hit-or-miss.

[Hangman]

Hi @Timtoon,

So you can't Open aliased files in Publisher but you can Place them, so I'm unsure whether or not that points to a bug.

When Placed the reference is always back to the source file which means you can move both the Publisher file and the Linked files to any location completely independently of each other and the Link is always maintained, i.e., you could move the Publisher file to one folder and the Linked files to a completely different folder and because the Link is always back to the source files, Resource Manager is happy...

I don't know if that is what you were looking to achieve...

[stokerg]

On 4/11/2024 at 6:14 PM, Timtoon said:

Were that the case, I wouldn't have filed the bug. The original images are not broken; they're the same ones I was using before. The aliases aren't broken because the originals they point to are still there.

Try this and see what you get:

1. Create Publisher doc1.afpub and a directory of images at `images1/`
2. Duplicate doc1.afpub to doc2.afpub
3. Duplicate the `images1/` directory and its contents for doc2.afpub and name it `images2/`
4. Open doc2.afpub and in the Resource Manager, update the image directory to `images2/`. It should all still work.
5. In the Finder, delete the contents of `images2/` and replace them with an alias to each file in `images1/`. These are aliases to the fundamentally identical image.
6. Open doc2.afpub and Update the Modified images
7. Error "Failed to open file"

At first i couldn't replicate this, but I've found out why.  I was creating my alias in the same folder as the images, so the files were named 'imagename.png alias' and this just worked.  However, I then created the alias outside of the folder with the images in so they are missing the 'alias' part from the file name and then I can replicate the issue you show.

If you can just confirm I've done this the same way as you have, I'll get this logged with the Developers