dealing with corrupt files or "unable to save" situations

[NotMyFault]

Lately quite some threads got started where users complain about getting corrupt files, or are completely unable to save a file.

Most impacted is Publisher, but other Apps are affected, too.

Dealing with linked resources seems to be one common factor - not ruling out situations where linked resources are irrelevant.

Symptoms (from memory) are

• Lost access to file
• Cannot save
• Truncated files (0 Bytes size or far to small size)
• This file is corrupt and must be closed now

I suggest that Affinity creates a new dedicated (non-public) sub-forum for all these cases. Only Affinity staff is able to deal with such cases.

Some general factors are known (store on internal disk, check enough capacity of drive, avoid cloud sync apps accessing the same folder, avoid direct storage on NAS etc), but no root cause is known for other cases.

If a user has a corrupt file, nobody except Affinity staff can help trying to repair in complex cases.

From the view of a user having this problem, it is totally frustrating getting answers only from other forum member who are unable to help in "hard" cases.

It would relief impacts users, other forum members, and the reputation of Affinity if all these cases get directly handled by Affinity staff.

Edited January 13, 2022 by NotMyFault
added non-public, added in complex cases

[NotMyFault]

Example threads:

https://forum.affinity.serif.com/index.php?/topic/155298-failed-to-save-document-save-failed-because-you-do-not-have-permission-to-create-a-file-in-that-location/&tab=comments#comment-875621

https://forum.affinity.serif.com/index.php?/topic/155277-failed-to-save-document/&tab=comments#comment-875485

https://forum.affinity.serif.com/index.php?/topic/59125-help-save-failed-because-the-file-could-not-be-written-to/&tab=comments#comment-873745

 

[GarryP]

While this might sound good from a user/support perspective I don’t think it will look good from a marketing perspective on the part of Serif.

It would essentially be saying: “Our software corrupts user files so often that we have specifically created a dedicated area of our forums for people to give us their broken documents to fix.”
It doesn’t really show the software in a ‘good light’, even if that is what is actually happening.
While I would applaud Serif for being so open/transparent by doing so, I don’t think it would be a good move publicity-wise for them to do it.

Probably better for the Serif staff to notice and respond to these threads earlier so that us general forum users don’t need to get involved in such things. Or, even better, to do something to stop people getting ‘corrupted’ files in the first place (which, of course, could be easier said than done).

[NotMyFault]

2 hours ago, GarryP said:

While this might sound good from a user/support perspective I don’t think it will look good from a marketing perspective on the part of Serif.

It would essentially be saying: “Our software corrupts user files so often that we have specifically created a dedicated area of our forums for people to give us their broken documents to fix.”
It doesn’t really show the software in a ‘good light’, even if that is what is actually happening.
While I would applaud Serif for being so open/transparent by doing so, I don’t think it would be a good move publicity-wise for them to do it.

Probably better for the Serif staff to notice and respond to these threads earlier so that us general forum users don’t need to get involved in such things. Or, even better, to do something to stop people getting ‘corrupted’ files in the first place (which, of course, could be easier said than done).

Agree.

It might be best if Affinity offers a non-public channel, with prompt reaction time. My main point is to offload these cases from the general public forum - which is unable to handle them appropriately.

[GarryP]

I notice that you added “non-public” to your original post but, since anyone can create a forum login, I don’t know what you mean by “non-public” in this case.

Anyway, a “Send document to Serif” button on the error dialog, in certain cases, might be another idea but I think that might have it’s own problems, e.g. Linked documents; Internet connection/bandwidth, etc.

If that’s too much trouble then having an email address in the error dialog, in certain cases, which people can send stuff to might be easier to set-up. (The accompanying message would have to make it clear that the supplied address should only be used for sending broken documents and not just for general help.)

Whatever happens, if anything does, I agree that if would be nice if there was a way for users to send problem documents to Serif without coming via the public forums. At the very least it would mean that users wouldn’t have to create a forum login (not all users have one) and then wait until someone gave them a cloud storage link.

Just as long as this communication method is not ‘abused’ by people, for example, either not understanding what it was for or thinking that they could get their problems looked at more quickly bypassing the other methods.

[walt.farrell]

19 hours ago, NotMyFault said:

If a user has a corrupt file, nobody except Affinity staff can help trying to repair

That's not completely true. If the document can be shared publicly, sometimes a forum user can recover the document. Sometimes it just involves tricks like using a different Affinity application. Sometimes it involves using Add Pages from Document in Publisher, and sometimes it involves Placing the file. And sometimes it involves other tricks that have not been fully described.

But sometimes the document can't be shared publicly, and sometimes the usual tricks that some users know don't work. In those cases, if anyone can help it's Serif staff, and even they may not succeed.

[walt.farrell]

19 hours ago, NotMyFault said:

I suggest that Affinity creates a new dedicated (non-public) sub-forum for all these cases.

That could work, if the forum software that this site uses has that function. I'm not sure it does. It would require being able to set the forum permissions so a user could post in a forum but not see other posts in the forum.

[NotMyFault]

3 minutes ago, LondonSquirrel said:

That is not correct. I am not a member of Affinity staff, but I recovered a file for somebody here in the forums and offered feedback on what caused the corruption.

Can I do it always? No. I've also seen other people recovering files.

I‘ve added „in complex cases“ to distinguish.

[Leigh]

On 1/13/2022 at 11:35 AM, NotMyFault said:

Agree.

It might be best if Affinity offers a non-public channel, with prompt reaction time. My main point is to offload these cases from the general public forum - which is unable to handle them appropriately.

Feel free to give out our direct email address affinitysupport@serif.com if you get to a thread before Serif staff. Technical Support/QA will normally try similar processes to the ones that you all try when trying to help a customers. If that fails, we then log the file with the developers to see if they can recover it or at least figure out what could have caused the issue.

The increase in these reports hasn't gone unnoticed by Technical Support and we'd like to thank everyone who has spent time recovering a file for a customer and/or has tried to recover a file without success. It's much appreciated 👍

[thomaso]

@Leigh, an update, FWIW: In the past weeks I experienced such "appears corrupted", "was lost", "must close now" errors with quite flexible frequency which doesn't hint me to any rule or recipe – except possibly this one:

It seems if I keep APub with one or two most used .afpubs opened over days or weeks (both files grow over time, one contains tests related to the forum) then the chance for this error gets increased after some days. Then it most often happens that "appears corrupted" or "must close" needs one or more trails to reopen these .afpubs, means a first trail can cause the error again while a second or third one does work fine. Actually, in the recent ~2 years with about ~50 of this error messages I got only 1 or 2 document states which I really could not open / really seem to be corrupted in the eyes of APub, while all others did open after several trials.

Also interesting that this message initially more often affects both open files rather than only one – and mainly (not only) if I come back to APub after a break with the mac 'sleeping'. This makes me assume it is a communication issue of APub itself with its own data (not my documents in particular), as if APub wasn't able to access or read its various temp files if the computer has slept for a while.

[GraphicsByGreg]

This file JUST randomly corrupted on me.  I've tried everything. If anyone can help I would be extremely grateful.  Thanks!!! 

LaTICE.afdesign

[NotMyFault]

Hi, can you explain the issue? What is corrupted, what parts of the file are important for you?

[GraphicsByGreg]

The file gets the "This file appears to be corrupt and must be closed"  It was working perfectly fine this morning and bam.  ...  no l linked files, and I work off my Mac not a remote drive. 

[GraphicsByGreg]

LOOKS LIKE IT WORKED!!! WOW!!!!  I BACKED up 100 copies hhahahaha WOW THANKS!!!     GraphicsByGreg.com   if you ever need any help with ANYTHING... let me know. 

[Leigh]

On 6/18/2022 at 12:20 PM, thomaso said:

@Leigh, an update, FWIW: In the past weeks I experienced such "appears corrupted", "was lost", "must close now" errors with quite flexible frequency which doesn't hint me to any rule or recipe – except possibly this one:

It seems if I keep APub with one or two most used .afpubs opened over days or weeks (both files grow over time, one contains tests related to the forum) then the chance for this error gets increased after some days. Then it most often happens that "appears corrupted" or "must close" needs one or more trails to reopen these .afpubs, means a first trail can cause the error again while a second or third one does work fine. Actually, in the recent ~2 years with about ~50 of this error messages I got only 1 or 2 document states which I really could not open / really seem to be corrupted in the eyes of APub, while all others did open after several trials.

Also interesting that this message initially more often affects both open files rather than only one – and mainly (not only) if I come back to APub after a break with the mac 'sleeping'. This makes me assume it is a communication issue of APub itself with its own data (not my documents in particular), as if APub wasn't able to access or read its various temp files if the computer has slept for a while.

Thanks for the update and information - very useful. Will try and replicate, making sure to pass any findings to our developers.

[Leigh]

On 6/18/2022 at 12:20 PM, thomaso said:

@Leigh, an update, FWIW: In the past weeks I experienced such "appears corrupted", "was lost", "must close now" errors with quite flexible frequency which doesn't hint me to any rule or recipe – except possibly this one........

I wanted to give you an update on this. i've been trying to replicate this scenario on my iMac but couldn't. Will try again on a Windows machine when I get chance. Thanks again for sharing your experience and if I manage to replicate the issue, I will let you know 👍

[thomaso]

1 hour ago, Leigh said:

I wanted to give you an update on this. i've been trying to replicate this scenario on my iMac but couldn't.

Same here: none of these issues occured in the last months / since my post. – In case you know of / detect a macOS protocol which gets written for any of these situations let me know. When it happened frequently I did a search for some keywords respectively certain dates/times but did not find any in the complex folder structure offered by the Console.app.

[thomaso]

On 7/5/2022 at 11:52 AM, Leigh said:

I wanted to give you an update on this. i've been trying to replicate this scenario on my iMac but couldn't.

This seems to be a rough recipe to replicate the error "Access lost ... while loading … Must close now":
At least I was able to reproduce it ~ 5x with my test .afpub which grows daily (currently 165 pages).

With a "large" document (= which creates quite a few temporary data / large .autosave) do some complex changes and save the document. Then closing the document and immediately reopen it (via open recent) appears to cause this issue for me and requires to get reopened one or two more times to avoid the error. Once it opened without this error I can't use this way to trigger it again, unless I worked in it again for some (unspecific) time and tasks.

Since this .afpub (165 pgs) can be opened and does not cause issues while working in it I assume the error is triggered by a conflict of temporary data which
a.) need to get deleted (<– closing the .afpub) and
b.) get created (<– reopening the same file),
as if this two tasks cross each other in the background. – In every case I see the document / layout as opened + get the missing font warning + get the missing resources dialog before the error occurs, which implies in my view there is no issue with this document at all but rather with get handled "in time" by APub.

[Leigh]

Thanks for the update - will try again 👍

[NotMyFault]

On 1/13/2022 at 1:33 PM, GarryP said:

I notice that you added “non-public” to your original post but, since anyone can create a forum login, I don’t know what you mean by “non-public” in this case.

Even if every user may create an account, not all parts of the forum must be included in search index, or available for viewing without any account.

[Leigh]

On 7/7/2022 at 5:34 PM, thomaso said:

This seems to be a rough recipe to replicate the error "Access lost ... while loading … Must close now":
At least I was able to reproduce it ~ 5x with my test .afpub which grows daily (currently 165 pages).

With a "large" document (= which creates quite a few temporary data / large .autosave) do some complex changes and save the document. Then closing the document and immediately reopen it (via open recent) appears to cause this issue for me and requires to get reopened one or two more times to avoid the error. Once it opened without this error I can't use this way to trigger it again, unless I worked in it again for some (unspecific) time and tasks.

Since this .afpub (165 pgs) can be opened and does not cause issues while working in it I assume the error is triggered by a conflict of temporary data which
a.) need to get deleted (<– closing the .afpub) and
b.) get created (<– reopening the same file),
as if this two tasks cross each other in the background. – In every case I see the document / layout as opened + get the missing font warning + get the missing resources dialog before the error occurs, which implies in my view there is no issue with this document at all but rather with get handled "in time" by APub.

I've been trying to replicate this on both my macOS and Windows machines but still not getting the issue. I've also tried a few other macOS machines and it's still working as expected. Are you saving locally or a to remote/network drive?

[thomaso]

14 minutes ago, Leigh said:

I've been trying to replicate this on both my macOS and Windows machines but still not getting the issue. I've also tried a few other macOS machines and it's still working as expected. Are you saving locally or a to remote/network drive?

All items are stored locally only on the internal SSD.

In case I did not mention: It seems this issue(s) gets triggered more frequent if I keep working occasionally in this two opened .afpub files but without saving for several days.

Here screenshots 1-8.zip/ below a series of recent "can't open / file lost" followed by "corrupted" errors when trying to reopen. This series of errors started while saving one of the two opened .afpubs and then affected the other, too (which is not always the case!). Also, the Save process bar is at its end but APub got frozen and required force-quit.

Also note when trying to re-open the "twitter.afpub" its page / image previews appear sharp, then blurred, then sharp again.

Finally both this .afpub files resulted in "corrupted" errors, I needed to continue with them from the mac's timemachine backup. Then the most recent file versions (from the hourly snapshots) did not work, too – I assume because of not having saved they contained no different content then their last instance where the issues started.

If you know of any possible macOS console protocol please let me know. Again I could not find myself a possibly related one in the rich folder structure of protocols.

< click to enlarge gallery
......

[Leigh]

@thomaso I've not forgotten about this post

I've been working on a Publisher document and left it 5 days between saving and was still unable to get the error, which is a shame. I will pass the information to our QA team to see if it's something they can look into further to try and replicate. Thanks again for your continued patience.

[Leigh]

@thomaso Me again, sorry. Is it possible to send us one of the documents you were using? Might make it easier for us to narrow down the issue. If it is, please send it as a package and if you need a Dropbox link to upload it to, please let me know.

[thomaso]

@Leigh, which one do you want? Aside the healthy current file version of "twitter.afpub" I still have two broken versions of it (one of the two .afpubs mentioned in the screenshots above which refused to open):

Since I usually add content only the two broken and larger .afpubs seem to contain data garbage which probably was removed in the current version by a Save As.

Since the two broken files don't open any more I could not create a package of them but can send them as they are (as .ZIP?).
Instead or additionally I could send the current, healthy version which contains the same images. (Before packing I'd need to fix some missing image links that I either just moved or, unfortunately, occasionally have renamed after their use in .afpub was done.) – So which of that 3 do you want?

However, for an upload I'd prefer your dropbox.
According to the summary I guess the packed size of "twitter.afpub" would be a few hundred MB.

Also, I think I could find the other mentioned ("v1105 .afpub") in a backup. Let me know if it would be useful, too.
(I remember I had tried one then and it didn't open either, so I assume it was a backup of the same .afpub version which didn't open some days later.)