GavinEadie

Thanks, Nathan .. I've no idea what caused the freeze (and, as noted, Photo could have been the victim, not the cause), but it would seem that reproducing a sequence of edits of an image would be hard to reproduce because so many actions are like "vary saturation till it looks good". Regardless, if this happens again I won't be able to take the steps you suggested -- I could move the cursor, but quitting or launching any apps wasn't possible. However, I pulled the unified log for the time around the failure sudo log show --info --debug --start '2024-02-28 18:00:00' --end '2024-02-28 19:20:00' That generated a file of 1.5 million lines (350MB) which I will send if you want it. What I have enclosed are two derivations from that file: (1) all the lines containing the Photo process number and (2) all the lines containing "affinity" .. there's a lot of dross but maybe something that helps. The SIGKILL from the ssh session on the other Mac occurs around 19:10. affinity-process-log.txt photo-process-log.txt

What Application are you using? [Designer/Photo/Publisher] ... Photo Are you using the latest release version? ... yes Can you reproduce it? ... sadly, no Does it happen for a new document? ... Yes -- that is I had been working on it for about 10 minutes. If not can you upload a document that shows the problem? .. No If you cannot provide a sample document then please give an accurate description of the problem for example it should include most of the following: What is your operating system and version ... macOS Sonoma 14.3.1 Is hardware acceleration (in Preferences > Performance) ON or OFF ? ... whatever the default is What happened for you (and what you expected to happen) ... this is where it gets difficult. What happened is that Photos stopped responding. In fact, nothing would respond -- I tried all the tricks. Force-quit could not be invoked from the dock or from the three-key method. Some activity was possible including, thankfully, a screenshot (enclosed). I used Terminal on another Mac and could ssh into the unresponsive one -- I did a "ps", a "sudo kill -9 nnnn" on the Affinity process, which did not terminate the process or gain responsiveness back, and ultimately a "sudo reboot" to restart the Mac. Provide a recipe for creating the problem (step-by-step what you did) ... the best I can do is give you the screenshot. I will note that my intention was to rectify a fisheye lens image (or a part of it), had tried the "Layer > New Live Filter Layer > Distort > Lens Distortion ..." but that didn't produce the result I want. I looked for other "Lens" actions via the Help menu, found what you see in the screenshot ... end of story. Screenshots (very handy) or a screen capture/video .. OK, done. Any unusual hardware (like tablets or external monitors or drives that may affect things) or relevant other applications like font managers or display managers ... No. I do use an external display and Photo was using it. Did this same thing used to work and if so have you changed anything recently? (software or hardware) ... I've never had this happen before. AND, I'm can't claim absolutely that Photo caused the problem (Photo might have happened to be the active program when something else bad happened). I was hoping I could get a kernel dump or an application crash report .. no such luck. I'll look through the crash logs and see if I can find anything. I wish I could give you more to work with; this was a nasty failure. Terminal SSH.txt

Wow! Excellent explanation and good suggestions which I'll try. What follows is NOT for the casual Affinity user. It's also the result of incomplete information so it's NOT gospel. The Affinity developers know the truth, I'm doing some guessing .. caveat emptor. _____________________________________ Not so simple! References to files and directories hereafter are relative to "~/Library/Mobile Documents/" My goal: Photos, Designer and Publisher interacting with iCloud in the same way and I like your choice - stop using the 'app library' folders and get explicit. "Getting Explicit" creates directories in the "com~apple~CloudDocs" directory. This is very good strategy for reasons below. You said: "after removing the beta app .. I unsynced Publisher 2 beta from the 'Apps syncing to iCloud drive' menu which removed the folder and its contents" .. that appears to not be the case any more. All my three apps were "On" in "System Settings > iCloud > iCloud Drive > 'Apps syncing to iCloud drive'" .. I turned them all off and nothing changed. I didn't logout and login iCloud during that (that may be required but is a step too far) but I did restart the Mac. The names of the "~com~seriflabs*" directories are not related to their names in the Finder (and some don't appear in the Finder). Here's the correspondence on my Mac. Note that "Affinity Photo" is associated with a contained "Documents" directory and the others aren't. Also notice my Publisher directory is not an 'app lib' 6LVTQB9699~com~seriflabs~affinitydesigner → "Affinity Designer" └── Documents iCloud~com~seriflabs~affinitydesigner └── Documents → "Affinity Photo" iCloud~com~seriflabs~affinityphoto └── Documents iCloud~com~seriflabs~affinitypublisher 2 └── Documents iCloud~com~seriflabs~affinitypublisher~beta └── Documents iCloud~com~seriflabs~affinityshared └── Documents icloud~com~seriflabs~affinitypublisher └── Documents com~apple~CloudDocs/Affinity Publisher → "Affinity Publisher" └── xmas-cards.afpub All the above "~com~seriflabs~" directories are locked and cannot be deleted (even with "sudo rm"). This is because they have extra "com.apple.macl" attributes which mean, in short, nothing except the app referred to in this attribute can modify this file/directory - not Finder, not Terminal, etc. This lock is unbreakable unless SIP is turned off. My "com.apple.macl" for Designer: 6LVTQB9699~com~seriflabs~affinitydesigner/Documents: com.apple.macl: 00000000 05 00 5E 67 00 1E 5B 48 45 37 84 0F 33 AC 45 5A |..^g..[HE7..3.EZ| 00000010 8F D6 05 00 58 F5 86 31 E2 F6 4B 2E 90 AA AE 74 |....X..1..K....t| 00000020 16 31 C4 72 00 00 00 00 00 00 00 00 00 00 00 00 |.1.r............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| Each new version of the Affinity has, I'm guessing, a new identity and so has exclusive modify right to only its own directory. So Photo 2.3 can read, but not change, documents in the 'app lib' directory created by Photo 2.2 - any modified or new document will go into the new 'app lib' directory created by Photo 2.3. Similarly, a version 2.3 cannot clean up old 2.2, 2.0, beta, etc directories. [ For extra points, the app in the above attribute is referred to by the UUID: 58F58631-E2F6-4B2E-90AA-AE741631C472 .. probably "Affinity Designer 2.3" but ???] I'd bet that non 'app lib' directories don't suffer such complexity because they can be created outside the confines of an Affinity app. Creating such non 'app lib' directories for Affinity apps causes there to be two items with the same name in Finder's view [enclosure]. They are distinguished only by their "Kind" - which is only displayed in a Finder 'List' view. Never using 'app libs' would make a much cleaner iCloud use. Since forensic computing is not my expertise, I'm stopping.

Walt .. Thanks for the quick answer, and that this is being worked on, and apologies, in advance, for following this very minor topic down a rabbit hole for a moment longer. Dan C said in your attachment, "Unfortunately there's no way to stop this issue from triggering when connecting/disconnecting an external monitor" .. but this appears to me to not be correct because, at least, Mail and Safari both switch, and resize, to the 'native' monitor when the 'external' is unplugged and return to the original monitor with a resize when it's plugged back in. I admit this issue is minor and there's a decent work-around .. it's also reasonable that programming to cater for such an 'edge case' might be omitted, but it's not impossible.

I went to save a Publisher document and was offered an iCloud folder for storage [see enclosed image]. Nice except it was "Affinity Publisher Beta - iCloud" and I'm not running a beta (and haven't since mid-2021), so I went and looked at the ~com~seriflabs~ folders: drwx------ 3 gavin staff 96 Oct 15 10:43 6LVTQB9699~com~seriflabs~affinitydesigner drwx------ 3 gavin staff 96 Oct 15 10:43 iCloud~com~seriflabs~affinitydesigner drwx------ 3 gavin staff 96 Oct 15 10:43 iCloud~com~seriflabs~affinityphoto drwx------ 3 gavin staff 96 Oct 15 10:43 iCloud~com~seriflabs~affinitypublisher drwx------@ 4 gavin staff 128 Oct 22 13:03 iCloud~com~seriflabs~affinitypublisher 3 drwx------@ 3 gavin staff 96 Oct 15 10:43 iCloud~com~seriflabs~affinitypublisher~beta drwx------ 3 gavin staff 96 Oct 15 10:43 iCloud~com~seriflabs~affinityshared .. what a mess! Two Designer folders and three Publisher folders (Publisher 3!?) and, to add confusion, most of these are not visible in the Finder or Save dialog. It would be good practice during an install or update to review `/Library/Mobile Documents/` for antique seriflabs folders, and contained material, and move any documents to the right folder and delete the out of date folders. All but one of the above contained empty Documents folder (excepting Photos, which had files I expected), one of which was dated for the macOS epoch: gavin@ ~ % ls -al "~/Library/Mobile Documents/iCloud~com~seriflabs~affinitypublisher 3" total 16 drwx------@ 4 gavin staff 128 Oct 22 13:03 . dr-x------@ 152 gavin staff 4864 Oct 15 10:43 .. -rw-r--r--@ 1 gavin staff 6148 Oct 26 21:25 .DS_Store drwx------ 2 gavin staff 64 Dec 31 1969 Documents Lest I sound grumpy, I assure you I love all three products .. they are a joy to use .. clean, fast, correct and tasty. If I am grumpy it's because this (and my other 'screen' bug) are the first evidence of clumsy programming the Affinity has exposed to me. I know no software (especially my own!) is ever free of bugs but let's stamp on them when we can.

I usually use Publisher on a larger second screen. Today, I unplugged it to work elsewhere and when I opened my .afpub document it didn't appear on the Mac's screen at all. With some fiddling, I got to show up on the Mac screen but it opened at the size of the external (larger) screen so all edges of the document were off-screen. Is something about "last screen used" being retained and Publisher isn't checking either the presence or size of the when it opens a document.