Macos Publisher 2.4.0 beta 2240 update issue

[AP-]

Have large file open in Publisher, but saved.

Publisher alerts me of a new update, do I want to upgrade? Yes I do.

Click.

Click on install update and restart.

Attempt to open the file that was previously open, which should not have had anything written because it had been saved before the update, and it is coming up as corrupt.

Legitimate question is: Why does Publisher attempt to write to a file that is to all intents and purposes just open for read access?

And corrupt it.

[walt.farrell]

What version of macOS are you using?

16 minutes ago, AP- said:

Legitimate question is: Why does Publisher attempt to write to a file that is to all intents and purposes just open for read access?

When was it last Saved? Was it during the session where you were prompted to update? Or had you last Saved before that session, and only viewed it during the session where you did the update?

If you saved it during that session, then the Save probably corrupted the file. Which leads to the question of where you Saved it, and whether any cloud services were involved, or USB drives, or Network Attached drives?

[AP-]

Hello, @walt.farrell

That is a fair point.

It was saved on an external drive, across USB-C (on exfat ha ha ha, not particular robust, I grant you), in the same session that prompted the update (but from last night). And it the Mac went to sleep. I started using it again this evening, got the alert to upgrade, with the file still being open. I've been saving this file from the 2222 build no issues prior, if that did corrupt it, I wonder what caused it. One way or another, keen to figure out - to avoid it happening again!

There is nothing in dmesg. Nothing in the other logs to suggest write failure, certainly nothing that Publisher flagged up at the time.

How do you go about recovering this? It reads about two thirds of the file on the progressbar before aborting.

Maybe offer an option to work on a copy of the corrupted file of the things it can recover from it? That could be a feature - might not be too hard to implement: if cannot open normally, give option to recover, make a copy, read as much as possible, abort if corrupt data, or skip section and try further down in the file? I can imagine people in a production environment would have need of such a feature.

[walt.farrell]

1 hour ago, AP- said:

How do you go about recovering this?

There are several things you can try. For example, if the file contains Linked files, rename the directory they're in, so they will be missing. Sometimes, if the issue is with one of the Linked files, that will allow the Open to succeed.

Or, create a new file with compatible characteristics. Then use Document > Add Pages from File to see if you can recover some of the data.

Sometimes it works, often it doesn't.

It's better to try to avoid the problem by changing your workflow. Serif recommends Saving to a local drive and a directory that is not managed by a cloud service. 

If you're really concerned, you can try something like this to detect issues and try to recover before you get into this situation: 

1. Given a document named X, after some work, Save As X2. Then Save As X3.

2. Open X2. If I works, you can close X3, and keep working. 

3. Later, after working some more, do all this again, but this time using file names X3 and X4, keeping X2 unmodified as a backup.

Eventually you'll have a set of verified usable files, X, X2, X3, etc. At some point you can delete some of the older ones when you're sure you won't need to go back to recover something from them.

 

[AP-]

Thank, valid suggestions.

Normally for things that I am worried about I do keep incremental saves.

And I have to say, your Document -> add from file, suggestion, which I did not know was a thing actually works, where 'placing file' didn't (fails to create a temporary file error message), and plain opening it does not work.

In essence, all the assets were embedded, and somehow, this method recovers the entirety of the allegedly corrupt file. Uh, although deleting the initial blank page crashed the app. Lol. I'm going to have to open another bug report for this.

[AP-]

Interesting, now I get this - and no, using a different filesystem/path with no spaces or aliased thing does not work either...

[walt.farrell]

Try saving to a folder on your local system disk that is not managed by iCloud.

[AP-]

This is really strange.

Recover the document:

Create a new A4 document using the template. Pages are portrait orientation.

Document -> add from file, replace the page that's already there. The whole file loads up - 29 pages.

Attempt to save, fails.

Delete last page got 28 pages now, still fails.

Delete second to last page (page 28), succeed in saving.

Import all over again, check it's still not saving, done.

Delete everything but the problem page, so now the document only has 1 page. ** EDIT ** And that single problem page on its own saves.

Glad to supply any logs if that would help, but I don't think Publisher Beta prints off debug messages.

 

Uhhh... or, I am using the wrong flag, because, when it errors, I get nothing but the initial loading blurb, if I run the binary from the command line:

./Affinity\ Publisher\ 2\ Beta --debug
2024-01-17 21:28:29.395 Affinity Publisher 2 Beta[29695:5497562] CoreText note: Client requested name ".SFNS-RegularItalic", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2024-01-17 21:28:29.395 Affinity Publisher 2 Beta[29695:5497562] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
2024-01-17 21:28:29.406 Affinity Publisher 2 Beta[29695:5497562] CoreText note: Client requested name ".SFNS-RegularItalic", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2024-01-17 21:28:29.508 Affinity Publisher 2 Beta[29695:5497562] WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.
2024-01-17 21:28:30.653 Affinity Publisher 2 Beta[29695:5497562] Warning: Column selection is not supported in view-based table and outline views (<SchemeTableView: 0x30a145000>).
2024-01-17 21:28:30.680 Affinity Publisher 2 Beta[29695:5497562] Failed to select item with enum value -1!
2024-01-17 21:28:30.681 Affinity Publisher 2 Beta[29695:5497562] Failed to select item with enum value 0!

 

[AP-]

Hah! I have nothing managed by iCloud.

See, what I was doing was, trying to identify the problem page, then the problem object on that page, by selectively deleting things. Except, the problem page saves, when it's on its own, so I'm a bit stuck with that theory.