"Save as" over-writing original file

[npodonnell]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug

"Save as" feature over-writing original file. This is quite annoying on a project I'm working on, since I have to keep git checkout'ing the overwritten files to restore them.

To Reproduce
Steps to reproduce the behavior:

1. Open draw.io desktop, Create New Diagram
2. Draw something, eg. a square
3. File -> Save and name the file as x.drawio
4. Draw something else, eg. circle
5. File -> Save As and save as y.drawio
6. File -> Open and open x.drawio
7. x.drawio will have a square and a circle.

Expected behavior
x.drawio should have only a square.
y.drawio should have a square and a circle.

draw.io version (In the Help->About menu of the draw.io editor):

• draw.io version 13.6.2

Desktop (please complete the following information):

• OS: Linux

[m-mohamedin]

You'll need to disable autsave in order to get the expected behavior.
In your example, when the circle is added, it is saved to x.drawio by autosave

[npodonnell]

I think this is confusing UX.

Most traditional desktop apps which have a save / save-as don't auto save by default, users don't expect this behavior.

Maybe consider turning off auto save. When it's turned on, remove or disable the Save option because it has no effect. At least this will give users a heads up.

[DomHudson]

I agree, this behaviour is counter-intuitive and in some cases quite damaging. For example, if I wanted to produce two similar diagrams:

1. I draw the first diagram
2. I "save as" with one name.
3. I alter the diagram to produce a new one
4. I "save as" with a new name.

Other programs would have the two states saved in the two different files, but this behaviour means that both files are identical containing all changes.

This exact thing happened to me: I had to recreate the first diagram because the software overwrote it with the extra changes, and whilst doing this the software overwrote the second diagram again.

[m-mohamedin]

As we mentioned before, the app is set to auto save by default. So, any changes done up to the point of the "save as" are automatically saved to the first diagram. Once you saved as a new one, the changes are only added to the new one.

To change that behavior, disable auto saving.

Let us know if we get it wrong

[m-mohamedin]

@npodonnell disabling autosave will cause more issues when work is lost. Check online editors like office or Google document, they auto save and also have a save as

[npodonnell]

@ashrafteleb This is a desktop app. It's called drawio-desktop. It's not an online editor. Take a look at Photoshop, Gimp, Inkscape, the list goes on. These are similar to draw.io and they are all desktop apps and they do not auto save.

At the very least - disable or remove the save item in the menu if you want to keep the confusing UX, because it has no effect.

[hviridis]

I still regard the autosave implementation as disadvantageous. At least some kind of version control should be supplemented as undo/redo-cache is discarded on quit. Autosave feature should protect the user from unexpected data loss, e.g., with an online application in case of a network connection fault. Program termination in contrast to manually save a document might occur intended or unintended. An unintended term signal may lead to unexpected data loss as well, e.g., reboot is automatically initiated (I feel an extraordinary love on how the developers care to silently apply updates to Microsoft Windows).

Traditionally autosave feature has been accomplished by a hidden copy of the document and user intension is confirmed by manual save function. In case a user confirmation is missing on start of an application the user is asked if previous state should be restored (libreoffice, vim). This method can be found with online and with offline applications.

Nowadays some application concepts take a simplified approach and abandon manual saving (Etherpad, JetBrains Rider). This is as collaboration tools reasonably feature version control which requires regular or continuous synchronisation to cope with potential conflicts. Even applications that deal with single-state data like accounting system usually have at least rudimentary version control (automatic backups, recovery points).

I propose:

• If save button should persist it at least should be greyed out to immediately indicate autosaving. Alternatively it would be reasonable to adopt the menu entry to create a snapshot with a timestamp that is stored as part of the document.
• If autosave is enabled save button should be removed and "save as" should be renamed to "create a file copy and edit..." in order to provide an intuitive usage.

[codebling]

Disabling Autosave is good enough for me, though I can see that not everyone in here feels the same way. Perhaps if the Autosave checkmark was in the File menu beside the Save options, the current behavior would be more obvious and take fewer people by surprise.

[m-mohamedin]

In the next release, auto-save would be disabled by default. To prevent data loss, changes would be saved in an internal draft in case app had crashed or machine is turned off.

[davidjgraph]

Attempt to address this in 16.0.0. Feeback welcome.

[codebling]

Tested it out. Looks great! I see that autosave is disabled by default, now. "Unsaved changes" shows up as soon as any change is made, and with autosave disabled, my regular workflow operates as expected.

[codebling]

New build looks good, thanks! Can't find any obvious bugs. In terms of other feedback, I like the idea of the 'autosave' checkbox being in the File menu, nearish the Save options, though maybe there's a technical reason for it being in the Extra menu.

Thanks for all of the hard work!

[wmjordan]

To prevent data loss, changes would be saved in an internal draft in case app had crashed or machine is turned off.

If we don't want each action leads to auto-saving to a draft, can we control the auto-save as a postponed one--unsaved drafts are backed up periodically?

[codebling]

If we don't want each action leads to auto-saving to a draft, can we control the auto-save as a postponed one?

If Auto-save is on, it works as it did before. If Auto-save is off and changes are made to the open file, it saves a backup file (does not overwrite open file), and if the application crashes and the original file is opened, a dialog pops up showing unsaved changes from the last session. @wmjordan it sounds like you want to completely disable this functionality? (...why?)

btw ashrafteleb davidjgraph I tested the "internal/draft" autosave and it works like a charm. Nice work

[wmjordan]

Hi, @codebling , I am not supposed to disable the auto-save backup file feature completely.
I would like the auto-backup function is run at a several-minutes' interval, not after each change. Otherwise, it will consume much battery on my notebook.

[codebling]

It looks like there's already a debounce of 1.5 seconds, with a maximum interval of 30 seconds between autosaves

[wmjordan]

That option might not be what I need. It controls the auto-save, but now it is no longer the problem. The option in question is auto-backup, which is new to version 16. Like Microsoft Office, it has a configurable value of auto-recovery, and by default, it backups unsaved document every 10 minutes.

[m-mohamedin]

@wmjordan Currently there's no configuration for that. Please open a feature request issue.

Also, please let us know if you noticed a degradation in battery performance using the new version.

Thanks

[wmjordan]

@ashrafteleb
Thank you for replying. I will monitor the file system, see how draw-io behaves and open an issue when necessary.