File save loses all work, if other user changes file

[taharvey]

I just had an issue, that exposed affinity's (very) bad handling of file collisions. There are many things that come up in Affinity that reveal that it is not built on a Cocoa-native framework – but this is the worst so far.

I saved a changed a shared file (dropbox) that my employee had also changed. Affinity gave me a dialog box that said the file had aready been changed, and it was deleting my (4 hours) of changes.

YIKES! Whenever this happens in other Mac applications, the dialog give you the ability to "save as...". Or it saves, and appends the person and date to the name to make it different,

 

Please fix.

[fde101]

The Affinity applications do not get along well with the "cloud" storage providers.  They expect exclusive access to their document files while they are open.

Best practice is to make a local copy that is NOT in a cloud storage area, modify that copy, and copy it back after having closed it within the Affinity application where you are editing it.

I would not expect a database application to get along well with this type of storage, and I suspect there are aspects of the way these applications interact with their document files that are similar to the way databases work - I get the impression they are actually modifying the document files while you work, and if the document changes from underneath them, they no longer have the information needed to continue functioning, so they have no choice but to discard the document as the complete state is not maintained in memory?  (This commentary is based on observing the behavior of the apps, not on any inside knowledge of the file format).

 

As an aside, four hours between saves is WAY too long...  I strongly advise that you save your work more frequently no matter what application you are using!

[MEB]

Hi taharvey,
Welcome to Affinity Forums
This is known issue which we are still looking into improving. We recommend to not edit files directly from external drives/NAS (network drives/storage) and cloud synchronised folders as this may lead to lost of work/data due to loss of connection or files changes (in synchronised folders). Affinity apps don't load the whole file to memory for performance reasons and require a permanent connection/access to the file to ensure incremental saves/changes work properly. If the connection to the original file is lost we lose access to the required non-loaded data (to memory) to save the file to another location. Please use the internal system drive when working with affinity files. We are looking into ways to improve this.

[taharvey]

On 7/17/2019 at 6:49 AM, fde101 said:

As an aside, four hours between saves is WAY too long...  I strongly advise that you save your work more frequently no matter what application you are using!

As a Mac user... "save" feels very 1990s.

Most of my applications are "stateless", meaning there is no difference between the memory state, the undo history, the file, and cloud versions. It is a all a continuous stream. I rarely think about "save", crashes, on, off, sleep... the file always is exactly where I left it. Save feels kinda retro.

But on this topic, native Cocoa applications continuously stream to the disk too. That said, they handle collisions gracefully. In fact if I pull up a file that one of my employees is editing, our applications continue to work, by save out: "filename - changed by joe blogs on X/X/X date"

[fde101]

1 hour ago, taharvey said:

"save" feels very 1990s.

I've been using Macs since the whole "auto-save" thing was a thing - it still isn't.  It's an illusion presented by some minor changes in wording and a decision to have software save over your files without asking.  There are pros and cons to that, but one of the cons is that it lulls people into a false sense of security that they don't need to save periodically as they assume the OS is doing it for them (sometimes it does, sometimes it does not), then if the power goes out or an app crashes at an inopportune time they lose that much more of their work.  Macs are still better than the alternatives, but this particular change is a misfeature and should not have been made.

[taharvey]

On 7/26/2019 at 8:47 PM, fde101 said:

sometimes it does, sometimes it does not

It think you misunderstand the underpinnings in the software. It ALWAYS saves... with every character stroke even if the file has never been saved... IF the application is fully native coded in the Cocoa framework. Yes, common applications built on external frameworks don't do it (Adobe, Microsoft), but "Built For MacOS" applications do... always (Omnigraffle, Pages, Numbers, etc)

 

I've never saved a Pages file in 10 years, and 1000s of pages of documentation... Every time I open the application, for even unsaved files, there I am right back where I left it. Never experienced a loss of data. Yet MS Word crashes a loses data even when continuously saving. 

[fde101]

On 7/28/2019 at 1:15 AM, taharvey said:

It ALWAYS saves... with every character stroke even if the file has never been saved...

No, it tries to give the illusion of doing that... if it actually did that it would be a performance nightmare.  It tries to save frequently, but not with every character typed.  Even so some apps are still impacted enough that disabling the feature improves their performance.

 

The underpinnings are described here: 

https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/StandardBehaviors/StandardBehaviors.html

[taharvey]

17 hours ago, fde101 said:

No, it tries to give the illusion of doing that... if it actually did that it would be a performance nightmare.  It tries to save frequently, but not with every character typed.  Even so some apps are still impacted enough that disabling the feature improves their performance.

To be clear. I am a software architect. This is no illusion, it is in fact the way it works.

And no, it is not a "performance nightmare". But yes, it does optimize by using time coalescing so there aren't millisecond changes to disk. That said, you can watch the update rate if use turn on sharing with another person. The updates to disk, or even with latency a full round trip disk->cloud->disk in sharing, are on the order of less then 200-500 milliseconds... fast enough that there is effectively no loss to any lack of save or crash... ever.