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

[Alex_M]

Hi Affinity team,

I was working on a document when I decided to save my work. The save progress bar hanged at ~50% for about a minute and then I got this error message: "Save failed because access to the file was lost". See screenshot below. Of course, I lost all my work on this document.  This is probably the 3rd or 4th time I get this issue in the past month or two. This didn't happen with Affinity Photo version 1. It only started  happening after I upgraded to V2. Kindly look into this major issue and fix it ASAP or I will be forced to move back to Adobe. I can't afford losing work, time and money due to this problem anymore.

[stokerg]

Hi @Alex_M,

Can you give me some more information about your set-up?  I can see from this thread you did have this error with V1 and from Chris B's reply there is mention of mapped network drives.  Is this still the case and you work from a network drive?

 

[Alex_M]

Hi, @stokerg. Thanks for the quick reply. That old thread of mine you are referring to is a different issue where the file can't be saved, but at least the program doesn't close without saving my work. That is an equally frustrating problem, but not as major as losing my work since I can save on my local disk when it occurs.

My setup is a pretty standard one. I work on my local machine and when I'm done I save my work on a mapped network drive. The mapped drive is located on a PC in the same local network. The mapped network drive is Western Digital Red Pro 8TB HDD.

[v_kyr]

9 minutes ago, Alex_M said:

I work on my local machine and when I'm done I save my work on a mapped network drive. The mapped drive is located on a PC in the same local network.

Save instead locally and copy the local saved file afterwards manually over to the network drive. - Remote drives might have connection access timeouts, be in power saving mode and the like, which then will yield to such a behavior. Thus better save locally first of all!

[Alex_M]

13 minutes ago, v_kyr said:

Save instead locally and copy the local saved file afterwards manually over to the network drive. - Remote drives might have connection access timeouts, be in power saving mode and the like, which then will yield to such a behavior. Thus better save locally first of all!

That's an interesting theory, but If that were the case, why is Affinity the only software that gives me these issues? I've never had this happen when saving files on the network drive with other software or when copying stuff on it manually. The biggest question here is why is Affinity outright destroying my work instead of showing an error that it couldn't save the file and ask me to save elsewhere?

[stokerg]

Hi @Alex_M,

18 minutes ago, Alex_M said:

That's an interesting theory, but If that were the case, why is Affinity the only software that gives me these issues?

I suspect this is due to the way Affinity loads and saves files (favouring speed, where possible), officially our developers recommend loading/saving files should be done to a local disk.  Then move the file to the Networked drive. 

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.

We also have a report logged with the Developers about Saving issues and the report does mention the error you are getting.  I will update that report with a link back to this thread and we can keep you posted on any updates regarding this  

27 minutes ago, Alex_M said:

The biggest question here is why is Affinity outright destroying my work instead of showing an error that it couldn't save the file and ask me to save elsewhere?

Yup i agree, offering a Save As would make sense.  I suspect it could be by the time that error is triggered the file has been 'lost' and Save As isn't an option. I have seen it brought up before from others who encounter this, that a Save As option would be a benefit.

[Pšenda]

1 hour ago, v_kyr said:

Thus better save locally first of all!

Until the errors with saving and corrupting files are removed, the application should explicitly inform/warn the user about this when saving to an external/network/cloud drive. The information provided here on the forum "officially our developers recommend loading/saving files should be done to a local disk" is of no use to these users who have just lost their valuable data.

[v_kyr]

1 hour ago, Alex_M said:

The biggest question here is why is Affinity outright destroying my work instead of showing an error that it couldn't save the file and ask me to save elsewhere?

Good question, it probably detects that too late here, aka being in some error state without further error handling options than an abort. Though it would be fine if it could react better here (try...catch) and offer then to perform a local save as instead.

21 minutes ago, Pšenda said:

Until the errors with saving and corrupting files are removed, the application should explicitly inform/warn the user ...

It's up to the Affinity dev team to do some better file i/o (pre)checking job here and then offer these informations directly from the apps in certain situations. - All we can do here in the forum instead only is, to remind people/users to better save files locally and also always to keep continiously backups, in order to prevent (and being prepared for) any possible data lost when using remote drives!

[GarryP]

If, to achieve better loading times (and maybe some other things), the Affinity applications don’t load all of the document into memory at once, and if there is then a problem accessing the file, then whatever could possibly be saved – only that which is currently in memory – may not be the whole document.

E.g. User has only viewed the first 10 pages of a hundred-page document so the software doesn’t load the embedded images (and whatever other things it needs) to display the other 90 pages that haven’t been viewed, and so they can’t be saved to the new ‘recovery’ document. (This is probably a vast simplification of what actually happens, or may not be anything like it, it’s just a simple way of looking at it.)

To put that another way, <something> could possibly be saved but the content and reliability of that <something> may, in some cases, not be much better than nothing.

However, as with some others, I agree that it would be nicer for the user to have the choice of saving whatever the software can save rather than all of it always being lost. At least that way there may be some possibility of copy/pasting from the ‘recovery’ document into the previous version when access to it can be regained. In other words, it would be better to let the user decide if what remains is usable.

[walt.farrell]

1 minute ago, GarryP said:

If, to achieve better loading times (and maybe some other things), the Affinity applications don’t load all of the document into memory at once, and if there is then a problem accessing the file, then whatever could possibly be saved – only that which is currently in memory – may not be the whole document.

I was just composing a post to suggest that possibility

[R C-R]

3 hours ago, GarryP said:

However, as with some others, I agree that it would be nicer for the user to have the choice of saving whatever the software can save rather than all of it always being lost.

But without knowing how much of each object's data & its relevant metadata might be in memory at any given time, it may be that there is little or nothing usable worth saving if access to the file is lost. Depending on the zoom level & document size(s) there could be not much more than mipmaps in memory for lots of objects.

Personally, I think the only thing that makes sense for this situation is a warning when opening a file that is not on a local drive.

[GarryP]

13 hours ago, R C-R said:

Personally, I think the only thing that makes sense for this situation is a warning when opening a file that is not on a local drive.

If that is possible – I don’t know how this sort of thing works these days with all of the different types of storage and access methods – then I would have no objections at all to that as it seems wholly sensible given the problems we have seen over the years.

It would also be nice if it were documented in the Help so that the people who look for it can find it without needing to ask about it here.

[firstdefence]

Obviously only people who have lost, corrupt or save fails and subsequently cannot open their files will post but I wonder how many people save or work from a network space/cloud/external device (USB - Thunderbolt etc) and have no problems? like what percentage of those people have no issues?

[thomaso]

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

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.

On 4/29/2023 at 10:24 AM, firstdefence said:

I wonder how many people save or work from a network space/cloud/external device (USB - Thunderbolt etc) and have no problems?

Is there a clear / direct relationship between the issue and external drives?

I experience – without ever using any external storage for Affinity & related files – this and the various similar errors, messages and file corruptions several times a year (Ø 1-2 per month, sometimes 2 per week). Most often when Saving a document, occasionally when Opening but nearly never when Working in small, new or in two long lasting documents with several hundred pages.

When this happens while Saving then it often (not always) affects all open documents (the message occurs for each) or APub freezes with its save process bar for the first file. Then most often it is followed by a corrupted document message + file, which in seldom cases can be used to restore the recent, unsaved changes into a document from the backup via "Add Pages from File…".

When it happens while Opening then it sometimes is sufficient to simply open the same file again, sometimes an app-relaunch is the required solution. In very rare cases it even happens that Opening results in the corrupted message + document, which appears especially strange because Open never should modify a saved file on disk but obviously does, visible by its changed modification date caused by Opening (<- without any chance to use a Save command!).

In my impression the culprit is in the way how Affinity handles & communicates with its .autosave and temp files. The mentioned external drives might increase problems but aren't the initial reasons.

[firstdefence]

All good points and insightful observation.

How many people would rather a save or open take longer and the file be intact, over that of speed and what difference would stability and file safety have on the overall speed of opening? I feel a few seconds more would count for nought compared to the hours of work lost.

Personally I feel like I've been quite lucky with files, although I don't generally work on larger documents where there is a bigger chance of error, especially the size of some documents that affinity creates. That said I've worked on rather larger video files with complete stability and no worry about corruption.

[R C-R]

17 minutes ago, firstdefence said:

How many people would rather a save or open take longer and the file be intact, over that of speed and what difference would stability and file safety have on the overall speed of opening?

I have no guess about that, but I think it is important to consider that the file size of some documents can be so large that all its data cannot fit into memory at the same time, & that if multiple files are open at the same time, this is much more likely to be true.

Consequently, some data will often need to be offloaded to VM on disk, so we also have to consider how much swapping that data between virtual & real memory will affect how quickly the app can respond to user input.

IOW, it is not just about load/save times but also about overall responsiveness.

[firstdefence]

11 minutes ago, R C-R said:

I have no guess about that, but I think it is important to consider that the file size of some documents can be so large that all its data cannot fit into memory at the same time, & that if multiple files are open at the same time, this is much more likely to be true.

Consequently, some data will often need to be offloaded to VM on disk, so we also have to consider how much swapping that data between virtual & real memory will affect how quickly the app can respond to user input.

IOW, it is not just about load/save times but also about overall responsiveness.

Agreed, maybe that's why Adopey Photoshop CC has the option for swap disks, to help take the pressure off larger files or multiple larger files. 

[R C-R]

8 minutes ago, firstdefence said:

Agreed, maybe that's why Adopey Photoshop CC has the option for swap disks, to help take the pressure off larger files or multiple larger files. 

I am sure that is why it does, & why Adobe recommends using as fast a drive as possible for the swap files. When no swap drive is available, or just slow ones, PS can get very laggy, almost to the point of being unusable.

[firstdefence]

30 minutes ago, R C-R said:

I am sure that is why it does, & why Adobe recommends using as fast a drive as possible for the swap files. When no swap drive is available, or just slow ones, PS can get very laggy, almost to the point of being unusable.

yeah it's quite bloaty, my fav version was Photoshop 7

[thomaso]

9 hours ago, firstdefence said:

How many people would rather a save or open take longer and the file be intact, over that of speed and what difference would stability and file safety have on the overall speed of opening? I feel a few seconds more would count for nought compared to the hours of work lost.

Yes, stability and speed are both aspects of quality – whereas instability causing data loss isn't just a matter of patience which may be required for slower speed.

But before questioning speed vs. stability, I'd rather wonder why Affinity often requires that the various available hardware acceleration options should get disabled by the user? If Affinity's high speed is cited as a reason for its instability: Are these options "too fast" for Affinity?

[firstdefence]

3 hours ago, thomaso said:

Affinity often requires that the various available hardware acceleration options should get disabled

This is a bit of an oddity, you would think acceleration would be a benefit not a disadvantage, for sure, something isn't quite right. Who knows what goes on backend and second guessing is not a productive method of criticism. I would choose stability and document safety over speed any day of the week; except Sunday when I can feel rather reckless at times  

Ultimately, it will remain a bit of a mystery to the majority of users and they will simply have to hope that Affinity can get on top of these problems or put a few safety nets in place, like automatic versioning and the like.

[walt.farrell]

7 hours ago, thomaso said:

But before questioning speed vs. stability, I'd rather wonder why Affinity often requires that the various available hardware acceleration options should get disabled by the user? If Affinity's high speed is cited as a reason for its instability: Are these options "too fast" for Affinity?

My guess is that the GPU drivers sometimes have bugs. We have seen reports, for example, of both these scenarios:

• Affinity was having issues with Hardware Acceleration, and updating the drivers to a new level fixed them.
  and
• Affinity was having issues with Hardware Acceleration, and reverting to an older driver level fixed them.

[thomaso]

1 minute ago, walt.farrell said:

My guess is that the GPU drivers sometimes have bugs.

Sure, driver software updates can solve issues. Whereas for macOS I haven't noticed forum recommendations to update system software items but rather to choose in the Affinity preferences "OpenGL" or "Software" instead of "Metal" for the GPU respectively to deactivate the "Metal" hardware acceleration (while "Metal" exists independent of the newer hardware architecture of Apple's silicon chips that may cause additional or separate or just fewer issues for Affinity).

[PaoloT]

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

I suspect this is due to the way Affinity loads and saves files (favouring speed, where possible), officially our developers recommend loading/saving files should be done to a local disk.  Then move the file to the Networked drive

Couldn't Affinity save to a local temp file, and then move it to the network drive?

Paolo

 

[walt.farrell]

1 hour ago, PaoloT said:

Couldn't Affinity save to a local temp file, and then move it to the network drive?

The error message is "Access to the file was lost" may indicate (as mentioned earlier) that the problem is with reading the rest of the file, as part of the Save operation, not with writing the file.

And in that case, your suggestion can't work. But it's a good thought, for some other situations.

For the general case, it probably would be appropriate for Affinity to:

1. Provide a mechanism to copy the file to local storage when you Open it; and then
2. Save it to local storage when you Save; followed by
3. Copying it to its original non-local location.