Publisher file broken

[Sam R]

I was working on a Publisher document when I got an error message:

<myfile> The document file was replaced during initial loading. The document must now be closed.

IIRC, I was replacing a linked image when the file was closed. When I tried to open the file again, Publisher said:

Failed to open file myfile.afpub. The file type is not supported.

I tried to add pages to a new document from the broken document but it didn't work. Can it be recovered?

The file was originally created in Indesign CS6, saved as an idml file and opened with Affinity Publisher 2.0.4. All images are linked. The file is on a external drive connected directly to a Mac running Monterey. TimeMachine is on, but somehow it hasn't backed up the directory since last December. 8-/

 

 

 

 

 

Edited March 31, 2023 by Sam R

[Dan C]

Hi @Sam R,

Welcome to the Affinity Forums & we're certainly sorry to hear this file isn't opening currently.

I'd like to request a copy of this .afpub file in order to investigate further and attempt to repair your document for you.

Can you please uploaded this to the below link for me?

https://www.dropbox.com/request/wd8OaWEIFAiMh4k0lWYJ

Once uploaded, please reply here to let me know. Many thanks in advance!

[Sam R]

 

File uploaded!

 

 

[thomaso]

6 hours ago, Dan C said:

in order to investigate further

Are there any news about possible reason(s) for issues like this (e.g. error messages like "can't read & must be closed", "failed to load", "access lost" et al.)? Though I reported them a few times with screenshots, system logs and uploaded Affinity files I still get them about once a months, most often triggered by "Save" (= no issues while working), usually followed by a frozen Save-progress bar + frozen app. About 2/3 of the cases get fixed by a simple app relaunch while about 1/3 result in a corrupted document. If reported as corrupted, the documents are usually lost / can get restored rather seldom via "Add Pages From File…".

I am very interested in avoiding these problems by possibly making appropriate adjustments in my workflow. It appears even frequent "Save" does not reliable prevent from the issue. All my files are stored on the local SSD of my mac, external drives or clouds never get used for Affinity files or placed resources. (but for timemachine backups only).

Any possible hint is appreciated!

[Dan C]

Many thanks for providing this file for me - I have tried to repair this using the tools available to me and have thus far been unable, meaning I will need to log it with our developers for further investigation.

Inspecting the file in a HEX editor does not show any clear signs of data loss/corruption, so this file may be recoverable though unfortunately we can offer no guarantees, our sincerest apologies.

We recommend reverting to a backup of this file if possible and we'll be sure to update you once our team have investigated this further.

On 3/31/2023 at 1:20 PM, Sam R said:

The file is on a external drive connected directly to a Mac running Monterey

We also recommend working on an internal drive with Affinity documents, then saving a copy of these files to external drives for backup purposes due to the way the Affinity apps load files, favouring speed.

_______________________________________

On 4/1/2023 at 6:57 PM, thomaso said:

Are there any news about possible reason(s) for issues like this (e.g. error messages like "can't read & must be closed", "failed to load", "access lost" et al.)?

Specific issues that can cause this to happen which can be replicated by our team, such as the 0x0 resource issue, are able to be resolved by our developers in a timely manner (for example the aforementioned issue is fixed in the 2.1 beta) however for seemingly random corruption, our team log these files with our developers not only to try and recover the document for the user, but also to try and determine the cause of the issue within the app.

For the files that we can determine the cause, this can then be resolved by our team in a future update. Unfortunately I don't have any further information regarding corrupted files at this time, as from your workflow it sounds as though you are following our recommendations.

[Sam R]

Thanks for looking into this.

I have now reopened the document and done again the edits (doing it the second i time is much faster ;-). So there's no need to recover the document for me. Unfortunately there was no backup.

I'm using an iMac, so adding internal drives is not possible. I keep my work on an external Thunderbolt drive and the setup is quite practical and fast. The internal drive is APFS, the external drive Mac OS Extended. The linked images are on a file server (an older Macbook Pro with external drives). If possible, I'd like to avoid spreading my layout files to several disks, to avoid confusion with file versions.

Are there any other reasons to use the internal drive, besides speed? Have you found any issues with differently formatted drives? Could there be a problem with the external drive's file system?

 

[Dan C]

Thanks for letting me know - I'll be sure to inform our developers to use the file for internal investigations to see if we can pinpoint the cause and stop this from happening in the future

33 minutes ago, Sam R said:

Are there any other reasons to use the internal drive, besides speed? Have you found any issues with differently formatted drives? Could there be a problem with the external drive's file system?

I certainly understand regarding your setup, my apologies as I could have been a bit clearer in my last reply - our devs recommend using internal drives not because they are inherently faster, it's due to the way that the Affinity apps specific handle file loading and editing.

The Affinity apps open files in a manner that favours speed, but comes with the downside of being slightly less stable when editing from external devices, USB drives or network locations. For this reason our team recommends using internal drives where possible to reduce the chances of said corruptions occurring.

As above we're constantly working to update and improve our file handling, including stability from such sources.

I hope this clears things up!

[thomaso]

11 hours ago, Dan C said:

Unfortunately I don't have any further information regarding corrupted files at this time, as from your workflow it sounds as though you are following our recommendations.

8 hours ago, Dan C said:

our team recommends using internal drives where possible to reduce the chances of said corruptions occurring.

Thank you for the reply. So I still try to detect what might cause the occasional issues respectively corruption in my situation. Sam's several disks made me wonder if my setup might cause confusion for Affinity. Do you or the team have an idea whether it might matter if the internal SSD AFPS drive is split into several volumes but on 1 container? If I remember correctly I experience these issues a lot more frequent since I am working in the setup below, where apps + user folder is on 'macOS' while I use "D_3" to store all files related to Affinity. So, Affinity has to communicate sort of permanently between its system folders on "macOS" and my documents and resources on "D_3". – Any hint?

[Dan C]

19 hours ago, thomaso said:

Do you or the team have an idea whether it might matter if the internal SSD AFPS drive is split into several volumes but on 1 container?

I don't personally, but I have asked this of the relevant teams and I will be sure to respond here ASAP with any information I'm provided

[Dan C]

Our devs have confirmed that there's nothing we're aware of in regards to your setup that would cause an issue, or that would increase the frequency of corrupted files - equally one of our experts mentioned that they use separate APFS volumes on macOS and don't experience such corruption, so we don't believe this to be a cause.

They did however reaffirm that file corruption is something we're still actively working to reduce and we hope that future updates should continue to improve the Affinity apps compatibility with external drives/cloud sources etc.