Affinity Photo Document File is Corrupted

[Alfat]

I open 2 affinity photo files at the same time, and work on one of the files... let's say file A and file B... I'm working on file A to crop the image, and suddenly my AP forces close... after I run it back, and I open file A, it's no problem.. but when I open file B, file B I have a problem, "Document FIle is Corrupted" . Please help me, because this file is my work file which is quite important.

Brief specifications of the computer I use:

Ryzen 5 5600x
VGA RX570 4Gb
Windows 11 21H2

I save the affinity file on the WD Book 4Tb external hard drive.

Please help me sir....

1398728283_AiskaHijabFeed.afphoto

[v_kyr]

Welcome to the forum!

Don't and never work directly on Affinity files which are opened on/from external drives/NAS/cloud space, this might sooner or later lead to file integrity problems and possible data lost. Instead always work on files copied and accessed on/from the local file system!

If you are lucky some dev may can rescue/recreate parts of your corrupted file, but I won't always count on that, so better always work on your local file system with Affinity files.

[RobWu]

5 hours ago, v_kyr said:

Welcome to the forum!

Don't and never work directly on Affinity files which are opened on/from external drives/NAS/cloud space, this might sooner or later lead to file integrity problems and possible data lost. Instead always work on files copied and accessed on/from the local file system!

If you are lucky some dev may can rescue/recreate parts of your corrupted file, but I won't always count on that, so better always work on your local file system with Affinity files.

If this is really the case, this a major issue. E V E R Y  application can work just fine with files from a external location.
I never had any issues working from my Windows Server with Affinity, but if this is really the case I might just stop using Affinity software until this madness is fixed.

What is this? the 90's????

[v_kyr]

2 minutes ago, RobWu said:

but if this is really the case I might just stop using Affinity software until this madness is fixed

It's mostly/probably due to their proprietary own incremental working file format and thus not easily fixable now. - Do a forum search after that topic in terms of corrupted file data in order to see a bunch of such causes!

[Alfat]

Need Solution.. UP

[carl123]

Recovered file is attached...

 

AiskaHijabFeed-recovered.afphoto

[thomaso]

8 hours ago, v_kyr said:

It's mostly/probably due to their proprietary own incremental working file format and thus not easily fixable now. - Do a forum search after that topic in terms of corrupted file data in order to see a bunch of such causes!

There are not only "corrupted" documents, similar error messages also occur with purely locally stored Affinity documents & purely local contents, e.g. "can't read … must close" / "save failed … change not allowed … must close" / "access lost … must close" / "file type not supported", to me each time without any recognisable system triggering such errors. Fortunately, then often a second or third attempt can successfully reopen such documents, with only the last changes missing. Unfortunately, this doesn't work always.

I use other apps which save incremental, respectively permanently live in the background (e.g. the Apple Preview app, Adobe Lightroom, Microsoft Outlook) without those or similar problems. Although I use Affinity most frequent these errors make me assume the Affinity process has kind of a bad time management when updating its data in the background, as if it would conflict (or just feel confused?) with other (system) processes running parallel.

[Alfat]

1 hour ago, carl123 said:

Recovered file is attached...

 

AiskaHijabFeed-recovered.afphoto 761.13 MB · 21 downloads

Thank you for your help, sir, this really helped me a lot... for tips in the future how to prevent that mistake from happening again? besides saving files on the internal hard drive ... thank you very much sir 😀🙏

[carl123]

16 minutes ago, Alfat said:

besides saving files on the internal hard drive

Do backups.

[RichardMH]

Do backups regularly with different names so you're not over writing a good one with a corrupt one (should it happen again).

[thomaso]

@carl123, how did you recover it?

[carl123]

2 minutes ago, thomaso said:

@carl123, how did you recover it?

The tools I use are not available to the general public but in this case, it would have also been recoverable via Publisher's "Add pages from file" function.

It was not a bad corruption

[v_kyr]

5 hours ago, thomaso said:

I use other apps which save incremental, respectively permanently live in the background (e.g. the Apple Preview app, Adobe Lightroom, Microsoft Outlook) without those or similar problems.

What's should be the incremental internal file format of those at all?

[thomaso]

1 hour ago, v_kyr said:

What's should be the incremental internal file format of those at all?

For LR and Outlook it appears to be a kind of data base. The user data get stored into 2 files in proprietary formats while 1 is a package file, split into files & folders. The large filesizes of LR and Outlook with several GB each + their autosave function indicate that every user change must get saved by the app immediately & can not save the entire file size with each single change and thus saves incremental (maybe as single, possibly temporary snippets within the mentioned folder & file structure). For Preview it's it highspeed autosave, too, + it's history autosaves (~backups) which let me assume incremental saves. Also the iPhoto / Photos app saves into a package and, like LR and Outlook, can not get saved manually by the user at all which also indicates their principle of permanently saving snippets with single user changes.

I am less concerned with the comparability of hidden workflows or background file formats than with the fact that Affinity fails in handling its own data and can even render user files unreadable as a side effect and consequence where it would be 'sufficient' just to crash or freeze but without destroying user documents.

[v_kyr]

2 minutes ago, thomaso said:

For LR and Outlook it appears to be a kind of data base. ...

Those probably then use instead some embedded db like SQLite etc. for such purposes, which is not quite the same in contrast to an own developed incremental binary file format.

9 minutes ago, thomaso said:

I am less concerned with the comparability of hidden workflows or background file formats than with the fact that Affinity fails in handling its own data and can even render user files unreadable as a side effect and consequence where it would be 'sufficient' just to crash or freeze but without destroying user documents.

That's actually the possible bad sideeffect (under worst case scenarios) for their own proprietary file format & file handling. In terms of content r/w, there does not seem to be an absolutely safe handling and checking of their file integrity available.

[thomaso]

13 minutes ago, v_kyr said:

That's actually the possible bad sideeffect (under worst case scenarios) for their own proprietary file format & file handling. In terms of content r/w, there does not seem to be an absolutely safe handling and checking of their file integrity available.

This seems to describe the current situation, respectively known symptoms and consequences. But don't you think Serif could + should develop their proprietary document file format(s) in a more reliable way? I understand if that demands fundamentally different code and consequences for exiting documents but since these errors seem to be permanent / unsolvable it appears strange to hang on it because as longer the apps exist and get developed as more this consequences might matter or influence an increased number of existing user files. Or, with other words: should the reliability of saved user documents not have highest priority, even before speed, file sizes and the restore option in case of crashes? (aside the known memory hunger and the occasional oddities with the 'PersonaBackstore.dat')

Outlook seems to use 1 proprietary database format (without suffix but not a macOS 'package') + 1 folder containing many sub- and subsubfolders and various file formats according to the different contents:

Lightroom uses 1 proprietary 'catalog' file + 1 package …

… containing folders with multiple nested subfolders for files in one format + 2 .db files:

[v_kyr]

37 minutes ago, thomaso said:

Lightroom uses

• Ansprechen der Adobe Lightroom Katalog Datenbank über SQLite Abfragen

• Lightroom SQLITE Database Structure

• ... etc.

42 minutes ago, thomaso said:

Outlook seems to use 1 proprietary database format ...

• Is there a way to view/edit Outlook for Mac's SQLite database to edit the signature file?
   
• 
   
• ... etc.

[thomaso]

1 hour ago, v_kyr said:

Ansprechen der Adobe Lightroom Katalog Datenbank über SQLite Abfragen

Ah, this is interesting, thank you! (though I never got a corrupted data base in ~10 years using LR)

But what does it mean now for Affinity? Don't you think Serif could / should ensure more document stability / reliability? I guess you did not mention the incremental saves as an excuse but rather as a possible culprit, right? However, even incremental saves can have a more stable solution.

I assume their are various alternatives for Affinity to the current way to handle the data flow of open documents and user edits. Maybe a similar db would be a solution instead of the current – and anyway proprietary – file formats .afpub/.afdesign/afphoto respectively their temporary .autosave?

This thread reminds me to former issues with ID (15 years ago, up to v.CS6) where it happened ~once a year (at daily intense use) that I got an error when re-opening my created .indd. Then it mostly could get solved by opening the affected .indd on a different computer + re-save it to make it work at its initial computer. I never experienced what was causing these issues. (maybe because we worked in a network with all images generally stored on a server / while the graphic macs + this mac server was part of a Windows network whose users often delivered images to the mac server?) – However, at least there never was a taboo for ID to work with data from external drives.

[v_kyr]

14 minutes ago, thomaso said:

Don't you think Serif could / should ensure more document stability / reliability? I guess you did not mention the incremental saves as an excuse but rather as a possible culprit, right?

Of course no excuses here, they should try to make it as stable/reliable/foolprove as possible.

17 minutes ago, thomaso said:

I assume their are various alternatives for Affinity to the current way to handle the data flow of open documents and user edits. Maybe a similar db would be a solution instead of the current – and anyway proprietary – file formats .afpub/.afdesign/afphoto respectively their temporary .autosave?

I'm not sure this is absolutely possible here, without loosing any backwards compatibility to their former & actual file format and app versions then. - Further it also all highly depends on the complexity, structure and organization of their proprietary file format.

[thomaso]

4 minutes ago, v_kyr said:

I'm not sure this is absolutely possible here, without loosing any backwards compatibility to their former & actual file format and app versions then.

It does not appear to be wise (feels rather absurd) to stick with an error-prone procedure "just" because a change would affect existing documents. As longer this will get used as more possible affected documents will exist. ["Do we really want to put out the fire? Then everything will get wet!!!"]

As far I remember a certain app upgrade was the reason for ID to offer the additional conversion / exchange formats .xml and .idml. Accordingly a change in the file format could get an additional tool or format to update / convert "old" documents. Currently – after years with this set of various error messages – it doesn't appear to be on a way to get any better.

[Old Bruce]

11 minutes ago, thomaso said:

Accordingly a change in the file format could get an additional tool or format to update / convert "old" documents. Currently – after years with this set of various error messages – it doesn't appear to be on a way to get any better.

And the improved Application would need, could have, an option to save files in version one format for sharing with people like me who haven't upgraded. Obviously if that choice to save in an old file format was made then some bits of the file would be rasterized or converted to text or both and some stuff wouldn't be editable with a simple method introduced with the improved version's tools. The onus would be on me to upgrade to the new version.

[v_kyr]

25 minutes ago, thomaso said:

It does not appear to be wise (feels rather absurd) to stick with an error-prone procedure "just" because a change would affect existing documents. As longer this will get used as more possible affected documents will exist.

Tell that the already existing user base and see how it will react then. Will that be Ok for them (the user base) or not?

27 minutes ago, thomaso said:

...Accordingly a change in the file format could get an additional tool or format to update / convert "old" documents.

It could, but would they offer that, or would they tell people to go the PDF exchange route instead, in the manner as they did with their former legacy tools?!

[thomaso]

5 hours ago, v_kyr said:

Tell that the already existing user base and see how it will react then. Will that be Ok for them (the user base) or not?

Funny idea to make a poll if a bug (such a bug) should get fixed for the possible price of reduced downwards compatibility. 😉

5 hours ago, v_kyr said:

or would they tell people to go the PDF exchange route instead,

... or would they keep on going with these errors and damaged documents? All options are speculative. – I prefer the idea they will choose the third option: fix it + make it convenient for users with the goal to satisfy their customers with foresight. (as a mac user I never experienced the legacy tools, maybe they knew at that time already about the upcoming Affinity?)

[v_kyr]

14 minutes ago, thomaso said:

Funny idea to make a poll if a bug (such a bug) should get fixed for the possible price of reduced downwards compatibility. 😉

Was more meant that I'm not sure, if user base would be happy with some complete file format changes and no possible backward compatibility then. Thus fixing instead the possible file handling bugs for their actual file format, will for sure be more welcome by people.

25 minutes ago, thomaso said:

... or would they keep on going with these errors and damaged documents? All options are speculative. ...

The future will show!

27 minutes ago, thomaso said:

(as a mac user I never experienced the legacy tools, maybe they knew at that time already about the upcoming Affinity?)

Sure, you don't abandon something long time well established, without knowing that you've alraedy something else (new) in the pipeline!

[walt.farrell]

20 minutes ago, v_kyr said:

Was more meant that I'm not sure, if user base would be happy with some complete file format changes and no possible backward compatibility then.

There is no backward compatibility today for the Affinity applications. For example, 1.8 could not read native Affinity files saved by 1.9 or 1.10, 1.7 could bit read the ones saved by 1.8, 1.9, or 1.10. Etc.