My work just went poof! - "Save failed because access to the file was lost"

[cutout3]

4 hours ago, thomaso said:

… respectively what is "the" vs. "a" culprit for these kind of error and messages: To me they happen quite frequently but entirely without ever having an external drive in use for Affinity and its related files. Means, an unambiguous relation between these errors and external drives appears to be unclear … while external drives are no condition for the issues but rather one of various aspects – or 'just' coincidence, since there are also users without having these issues when using their external drive.

The fact that "the forum is full of such former user reports" does not mean that it is not also "full of" reports of users who did not use external drives but are affected by these issues, too. External drives appear to be a less reliable reason for issues than those issues that get caused by hardware acceleration on different platforms and operating systems, for specific tasks at least and reproducible for certain users.

I get the gist of your post, I think. Would you mind rephrasing this sentence, however? It's a little confusing.

"… respectively what is "the" vs. "a" culprit for these kind of error and messages: To me they happen quite frequently but entirely without ever having an external drive in use for Affinity and its related files."

[Pšenda]

5 hours ago, thomaso said:

External drives appear to be a less reliable reason for issues than those issues that get caused by hardware acceleration on different platforms and operating systems

Have you seen any reports here about file corruption and loss of work due to HW Acceleration? So I don't. However, I have seen dozens of reports here about corrupted files when using external drives. After all, even here, Serif himself has made recommendations about not using external drives for work files many times. And that includes a description of the cause of the errors - loss of connection with the disk. Ignoring this technical aspect and thus the risk of data loss is of course up to each user and their approach to their own work.

Edited May 6, 2023 by Pšenda

[thomaso]

I am sorry that I was not clear and was confusing you.

28 minutes ago, cutout3 said:

Would you mind rephrasing this sentence, however? It's a little confusing.

With "a" culprit I tried to express that an external drive can be somehow involved (~one reason) among other culprits, while "the" culprit means to me the actual, direct trigger and condition for the error. As far I see an external drive does not cause a reliable reproducible save fail / file lost / document corruption etc., … it may happen but doesn't have to.

20 minutes ago, Pšenda said:

Have you seen any reports here about file corruption and loss of work due to HW Acceleration? So I don't. However, I have seen dozens of reports here about corrupted files when using external drives.

No, I did not say that HW acceleration causes file corruption (respectively issues of this thread like save fails / file lost / etc.). HW acceleration causes other problems, but unlike external drives, disabling HW acceleration appears to reliably avoid its associated problems on affected computers (while not all seem to be affected).

Yes, there are dozens of reports of corrupted files on configurations with external drives – but imho there are also reports for computers with external drives that result in no corrupted files + reports for computers with no external drives that get corrupted files or associated problems or messages.

This means to me that it seems unclear whether external drives are THE cause / culprit in these situations.
Did users report the issues did disappear (not occur any more) to them because / since no external drive was used?

My impression (based on my experience with these errors mainly while saving, locally) is that these errors are a result of communication problems between the saved Affinity document and the files in the Affinity autosave and temp folders. Of course, a more complex data chain, e.g. with an external drive involved, may increase the complexity of the problem and decrease it if no external drive is used – but external drives do not directly cause the problems, even though they can make them worse. Thus the Serif recommendation to avoid external drives can be useful indeed but doesn't solve the problems.

[debraspicher]

Affinity "streams" the files it seems, which is different than dealing with entire copies of things. It's sort of like working with moving parts and pieces inside a container, but that container stays with the program that is currently working with it. It's not necessarily fully released back to the file system (but it's not locked for external edits either...) if that makes sense. It's open to changes while the program is open working with it, so it will be more error prone if anything interferes with access to the file itself and breaks this link. Perhaps this design is so the that the files can be accessed easily between Affinity apps for speed. That would make the most sense.

Other reasons for data loss are cited below by a staff member/moderator:

Personally, I know from my Adobe days to religiously save my work in revisions. This requires more space, but it's peace of mind. The bigger a file gets, the more likely corruption is to occur. Always backup! Corruption can happen for any reason, including power loss. Computers are not infallible. It's more likely with the way Affinity handles their proprietary format because of the way they are handled by the program, but in my opinion, the same precautions that we would take here applies to all production software, not just Serif's products.

I will say that in my case I do use Onedrive. I may change this, however, but for now it saves locally and I never access the files remotely and edit them causing potential for that data to change while it's open on my machine. It's not "good practice", but I'm not using my Cloud the way that 1) requires internet to access those files and 2) that those files are changed without notice to Affinity. It does not mean this means cloud usage should be recommended, because I'm 100% aware it's on me if I suffer data loss and what might cause this. Most users are not aware the conditions. I think that I don't have issues because Onedrive is 100% of the time uploading, not downloading. If I were to start editing these files on another machine and then save, forcing it to download to the original machine while the file was still being streamed (i.e. opened in Affinity), that's probably where risks for corruption increase.

[Pšenda]

7 hours ago, thomaso said:

This means to me that it seems unclear whether external drives are THE cause / culprit in these situations.

As I already stated, it is up to each user whether to ignore or respect the recommendation of the application developer (why else would he give this recommendation repeated many times, if it was not a "real" problem).

 

 

[thomaso]

3 hours ago, Pšenda said:

As I already stated, it is up to each user whether to ignore or respect the recommendation of the application developer (why else would he give this recommendation repeated many times, if it was not a "real" problem).

You misunderstand my posts. I do not say that avoiding external drives would not help to avoid these issues and I mention the possible influence of external drives – but the "THE" culprit in terms of the initial cause appears to be somewhere else than in using external drives.

As said a few times I experienced these type of issues frequently myself although I am using an internal SSD only … while the issue triggers various messages + results. Not all events with identical messages result in a corrupted document, while definitely more than 50% of this errors end in corrupted documents to me.

Note what @stokerg mentioned earlier in this thread:

On 4/28/2023 at 1:57 PM, stokerg said:

Having said that, I do know one of the Tech Team who saves directly to NAS drive without any issue, so it's possible there is something more going on in the background on certain network setups that's causing this.

[thomaso]

10 hours ago, debraspicher said:

Affinity "streams" the files it seems, which is different than dealing with entire copies of things.

I don't see a reason why this "streaming" (not loading the entire document and linked resources) into the current "working memory" (RAM and disk) would be the culprit for these issues. Yes, in my experience it seems these issues happen more often when a document was not saved for a longer period and saving frequently can reduce the number of issues. But I also get the issues for instance with new documents with just a bit of contents when saving them the first time. Or I experience this error (file lost / must close) when opening a saved document while a second trial to open the same file just seconds later does not cause the issue.

10 hours ago, debraspicher said:

Personally, I know from my Adobe days to religiously save my work in revisions. This requires more space, but it's peace of mind. The bigger a file gets, the more likely corruption is to occur.

Quite likely neither the technology of  "streaming" nor the document file size do or have to trigger these issues in Affinity. Consider that the DAM and image editor Lightroom works with its files 'catalog' (.lrcat) + 'previews' (.lrdata) that can be not only massively larger (several GB) + with more linked resources than average Affinity documents but also that Lightroom has no Save command at all. – Accordingly the question is what prevents Affinity with its similar folders "autosave" + "temp" from working in a reliable, continuous way? Or: why can the same situation (document, setup etc.) can cause an Affinity error but no error just seconds later? Unfortunately only app crashes get a system protocol entry but not document crashes.

[v_kyr]

1 hour ago, thomaso said:

I don't see a reason why this "streaming" (not loading the entire document and linked resources) into the current "working memory" (RAM and disk) would be the culprit for these issues.

The point is here probably more on the saving/writing I/O side than reading in, as the apps use a sort of incremental file format (similar to what better backup software offers with intial and incremental backup file chunks). In order to write out all related data of a certain document, it needs to have all that related data in some access. Then when saving/writing out all data it has to be prepared and placed into the structure needed by it's own overall file format. And therefor the apps might use internally some buffered file streams, which are then filled accordingly with all the needed compressed data chunks (initial + increments). Buffered file streams might here, for performance reasons, be manual buffered, as that often gives some speed gain in contrast to usual std library std::fstream functions. - Here in this scenario when saving with enabled doc history, the whole will probably contain even more data chunks, than usual without using that option.

Now where all the data (initial + update changes) should be included in some file stream, it has to be physically written out into a file. As the file can be created locally or remote (where remote = meaning here everything not being a local internal storage place), it can be dependent on how the used storage place, it's connection and drives behave. USB and certain network NAS connections are usually as default physically buffered themself, so might write the received data out only if their buffer has been filled, so slightly lagged. Also if some remote drives have their energy save modus enabled and are have been idle for some time, they might have before gone into sleep mode and have to benn wake up first. And so on ...

1 hour ago, thomaso said:

Consider that the DAM and image editor Lightroom works with its files 'catalog' (.lrcat) + 'previews' (.lrdata) that can be not only massively larger (several GB) + with more linked resources than average Affinity documents but also that Lightroom has no Save command at all.

Well that's a little bit like an Apple & Oranges compare here, as Lightroom uses SQLite databases for those catalogs and SQLite in turn grants and follows the ACID rules here.

 

[thomaso]

Thank you, @LondonSquirrel and @v_kyr, I guess I understand what you say about incremental, atomic, database. But is this sufficient to explain the various scenarios in which these problems can occur? Also, especially the kind of coincidence of resulting consequences of these errors appear confusing to me. For instance:

A. Save > file lost / must close –> Document re-opens fine and contains the saved modification.
B. Save > file lost / must close > corrupted –> Document can't get opened but can get restored via "Add Pages From File".
C. Save > file lost / must close > corrupted –> Document can't get opened and not get restored.
D. Open > file lost / must close –> Document opens fine a few seconds later (!!).
E. Open > file lost / must close > corrupted –> Document can't get opened and gets a new modification date although the user even had no chance choose "Save". (!!!! very rare but strange, too / never should be possible. Noticed 2x in the last 2 years + confirmed 1x by another forum user some weeks ago.)

In my experience it can work but also can fail to choose the recovery / restore option when launching Affinity after an app crash or a manual app close without having saved all open documents –> means, .autosave files may be useful or not while it appears fully unclear when they work. As if it is unclear to Affinity itself what gets in fact stored in the two temp data folders. The "Recovery interval" in my APub is set to the default 300 (= 5 minutes) whereas I definitely got modification recovered that I did within the last minute before a crash, – well, I can't tell when the last .autosave or temp file was saved.

Where are the last file modifications stored in the example below? Obviously not in the two temporary folders, although they immediately responded before to my back-steps in the history panel. What would happen to the last layout changes if the app would crash before the last save action?

[cutout3]

18 hours ago, thomaso said:

No, I did not say that HW acceleration causes file corruption (respectively issues of this thread like save fails / file lost / etc.). HW acceleration causes other problems, but unlike external drives, disabling HW acceleration appears to reliably avoid its associated problems on affected computers (while not all seem to be affected).

Yes, there are dozens of reports of corrupted files on configurations with external drives – but imho there are also reports for computers with external drives that result in no corrupted files + reports for computers with no external drives that get corrupted files or associated problems or messages.

This means to me that it seems unclear whether external drives are THE cause / culprit in these situations.
Did users report the issues did disappear (not occur any more) to them because / since no external drive was used?

 

11 hours ago, Pšenda said:

As I already stated, it is up to each user whether to ignore or respect the recommendation of the application developer (why else would he give this recommendation repeated many times, if it was not a "real" problem).

 

 

We need Columbo!   https://www.imdb.com/title/tt1466074/

Both of you make good points. One of you needs to go to jail!

Kidding! American humor, I suppose. Neither one of you is the 'killer'. 

[cutout3]

Serif, killed Mr. Green, with the candlestick, in the ballroom!

I solved the 'lost data' case!

[Pšenda]

2 hours ago, cutout3 said:

Both of you make good points.

If you noticed, in my post there is a citation from Ben - one of the main developers of Affinity applications, whereas with thomaso's its some weird and unfounded assumptions. What conclusion you choose from this is up to you - feel free to work on an external drive, but then don't be surprised if it fails one day (classically in the least suitable situation).

[Old Bruce]

17 hours ago, Pšenda said:

don't be surprised if it fails one day

If it fails 

should be

when it fails

[Sharkey]

If any of my external drives are not reachable (for whatever reason) and with the exception of all cloud stuff, then I do not save to them.

How do I know there are not reachable?  They do not appear on my display-so I check.

Glitches have been part of my workflow for 30+ years. It does not matter whose software you are using. It is your business/money. Do what is necessary to safeguard your work to the maximum of your ability because it is you that has to field the complaints, redo the work and explain to the bank manager why all the earnings just went 'poof'.

My office system was not expensive because it saved me a lot over the years. Now retired I don't see any real reason to recommend anything newton those still at it.

Use 'raids', at least two set ups. One on site permanently and the other removable (to take with you). Ensure they are big enough, fast enough and have historically reliable reports.

Permanently on, backed up to simultaneously.

When you have a problem STOP! Find the problem and fix it. If you cannot do that and your tech just whistles. Change your kit and count yourself lucky that it is only money and nothing terminal.🦈

 

[Sharkey]

On 5/4/2023 at 11:03 AM, Alex_M said:

I forgot that I opened a file on the network drive so when I saved I got the error message and lost all my work. This is an extremely serious issue with this software and should be fixed ASAP. I hope the Affinity team works on the fix.

May I suggest you fix the problem yourself. 

If it is that important 'stop doing' it and find something that works.

Continually doing the same thing WILL result in the same outcome.

I am sure your employer/ customer will also benefit knowing you are providing a reliable service and in time, you never know, the problem might not matter anymore.

 

[polite]

Wow, I came to the forum to see if anyone else was having this issue, I didn't expect such a torrent of victim blaming behaviour. 

I think it comes down to this: 

1. Yes, you can probably avoid this by not working on external drives/network drives. Though this will often mean copying files locally, working on them and remembering to sync back to their original location. 
2. The software could and should handle these issues by allowing you to save the file in a new location rather than closing and losing everything since last auto-save. Working off network shares is pretty common in most places I've worked for the last 30 years, in IT and design when you need to collaborate with people.
 

Hopefully it's not a difficult patch to the save function in the v2 suite.

In the longer term, I hope there are some features for collaborative work coming. Would be nice to see some check in/check out and versioning options. Does anyone have any nice workflows for this with the Affinity suite?

[Ron P.]

21 minutes ago, LondonSquirrel said:

Agreed. There is a bit much blaming the victim here. Better explanations are more useful than blaming.

When the person, intentionally, repeatedly, does what he has been told not to do, and gets the same result, then I fail to see that person as a victim. Smack your head into a brick wall, and discover it hurts, and others tell you, smacking your head into brick walls will result in pain, yet you continue to do so, are you really a victim? There's a more correct term.

 

[Sharkey]

On 5/9/2023 at 5:58 AM, polite said:

Wow, I came to the forum to see if anyone else was having this issue, I didn't expect such a torrent of victim blaming behaviour. 

I think it comes down to this: 

1. Yes, you can probably avoid this by not working on external drives/network drives. Though this will often mean copying files locally, working on them and remembering to sync back to their original location. 
2. The software could and should handle these issues by allowing you to save the file in a new location rather than closing and losing everything since last auto-save. Working off network shares is pretty common in most places I've worked for the last 30 years, in IT and design when you need to collaborate with people.
 

Hopefully it's not a difficult patch to the save function in the v2 suite.

In the longer term, I hope there are some features for collaborative work coming. Would be nice to see some check in/check out and versioning options. Does anyone have any nice workflows for this with the Affinity suite?

Not victim blaming. Just seeing something going wrong for which there seems no obvious fix.

Then an OP continuing (accidentally or not) to try the same operation more than is necessary to confirm the problem under some misapprehension that doing the same thing will eventually get a different outcome!

Until there is an answer do the job a different way. Blaming - no. Logic -yes.

 

[Affinity Info Bot]

The issue "Saving Failed increasing frequency of reports" (REF: AFP-4826) has been fixed by the developers in build "2.2.1 Release".

This fix is in the current customer release.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us