Lack of file overwrite prompt leads to data loss #87265

New Issue

Ludvik Koutny · 2021-04-07T11:51:20+02:00

Ludvik Koutny commented

2021-04-07 11:51:20 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.92

Blender Version
Broken: version: 2.92.0, branch: master (modified), commit date: 2021-02-24 16:25, hash: 02948a2cab
Worked: (newest version of Blender that worked as expected)

Short description of error
2021-04-07_11-44-58.mp4
Highlighting the file name field with red color in the save as dialog is by no stretch of imagination sufficient data loss prevention. Literally any other software out there which deals with creation and writing of user generated data files has an actual file overwrite pop up dialog exactly for this reason. It's not difficult to accidentally press save instead of open hotkey shortcut. It happens. And Blender should have user's back in this case instead of punishing them with data loss. If I did not do daily backups, I would lose 2 days of work right here. I know this is not technically a bug, but I am still reporting it as one, since data loss is very severe issue. Not having a file overwrite warning is just flat out unacceptable in this day and age.

Aside from the relatively easy to miss red highlight, the save and load dialogs are literally identical:

So some additional error prevention is really appropriate here. This isn't the kind of case where you can really say "You should have read better". In case of potential data loss, it's really important that the software leans on the side of helping the user out instead of punishing them.

Exact steps for others to reproduce the error

Start with a new empty .blend file
Press a "Save as" hotkey shortcut
Select existing .blend file and press enter
Result: If done in rapid succession, while user makes a mistake of using a wrong shortcut, no file overwrite warning is issued and user data in overwritten blend file is destroyed.
Expected: Blender has file overwrite warning dialogs like any other modern piece of software.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.92 **Blender Version** Broken: version: 2.92.0, branch: master (modified), commit date: 2021-02-24 16:25, hash: `02948a2cab` Worked: (newest version of Blender that worked as expected) **Short description of error** [2021-04-07_11-44-58.mp4](https://archive.blender.org/developer/F9922647/2021-04-07_11-44-58.mp4) Highlighting the file name field with red color in the save as dialog is by no stretch of imagination sufficient data loss prevention. Literally any other software out there which deals with creation and writing of user generated data files has an actual file overwrite pop up dialog **exactly for this reason**. It's not difficult to accidentally press save instead of open hotkey shortcut. It happens. And Blender should have user's back in this case instead of punishing them with data loss. If I did not do daily backups, I would lose 2 days of work right here. I know this is not technically a bug, but I am still reporting it as one, since data loss is very severe issue. Not having a file overwrite warning is just flat out unacceptable in this day and age. Aside from the relatively easy to miss red highlight, the save and load dialogs are literally identical: ![saveload.png](https://archive.blender.org/developer/F9922663/saveload.png) So some additional error prevention is really appropriate here. This isn't the kind of case where you can really say "You should have read better". In case of potential data loss, it's really important that the software leans on the side of helping the user out instead of punishing them. **Exact steps for others to reproduce the error** 1. Start with a new empty .blend file 2. Press a "Save as" hotkey shortcut 3. Select existing .blend file and press enter Result: If done in rapid succession, while user makes a mistake of using a wrong shortcut, no file overwrite warning is issued and user data in overwritten blend file is destroyed. Expected: Blender has file overwrite warning dialogs like any other modern piece of software.

Ludvik Koutny commented

2021-04-07 11:51:20 +02:00

Added subscriber: @Rawalanche

ariacarina commented

2021-04-07 13:30:52 +02:00

(Migrated from localhost:3001)

Added subscriber: @ariacarina

ariacarina commented

2021-04-07 13:30:52 +02:00

(Migrated from localhost:3001)

This comment was removed by @ariacarina

*This comment was removed by @ariacarina*

Dalai Felinto commented

2021-04-07 14:30:02 +02:00

Added subscriber: @dfelinto

vanessaaustin commented

2021-04-07 14:44:21 +02:00

(Migrated from localhost:3001)

Added subscriber: @vanessaaustin

vanessaaustin commented

2021-04-07 14:44:21 +02:00

(Migrated from localhost:3001)

This comment was removed by @vanessaaustin

*This comment was removed by @vanessaaustin*

Bastien Montagne commented

2021-04-07 15:22:18 +02:00

Added subscriber: @mont29

TheRedWaxPolice commented

2021-04-07 17:45:25 +02:00

Added subscriber: @TheRedWaxPolice

Harley Acheson commented

2021-04-07 19:43:37 +02:00

Added subscriber: @Harley

Harley Acheson commented

2021-04-07 19:43:37 +02:00

I personally don't like the idea of adding "are you sure?" confirmations for things like this, but I do find our current notification to be weak.

Showing the filename in a red box seems to be an incorrect notification in that it seems like the name itself is in error, like might be the case if you enter forbidden characters.

I'd much rather that the "Save As" button would be changed, since clicking that is the thing we want to warn against. So I'd like to see it say "Overwrite", be in our "caution" color (is a theme setting for Info), and a warning icon - ⚠ - added too.

I personally don't like the idea of adding "are you sure?" confirmations for things like this, but I do find our current notification to be weak. Showing the filename in a red box seems to be an incorrect notification in that it seems like the name itself is in error, like might be the case if you enter forbidden characters. I'd much rather that the "Save As" button would be changed, since clicking that is the thing we want to warn against. So I'd like to see it say "Overwrite", be in our "caution" color (is a theme setting for Info), and a warning icon - ⚠ - added too.

TheRedWaxPolice commented

2021-04-07 19:57:12 +02:00

@Harley Unfortunately, when working fast, a warning dialog is the only thing that can save you from this trap... There's a reason this is still standard everywhere...

So +1 for a warning dialog...

@Harley Unfortunately, when working fast, a warning dialog is the only thing that can save you from this trap... There's a reason this is still standard everywhere... So +1 for a warning dialog...

Ludvik Koutny commented

2021-04-07 20:29:51 +02:00

The thing is - Blender already sets the precedent by having a pop up prompt when closing an unsaved file. It's the same type of scenario. One could easily say "Just don't press the window close button if you are not sure you want to close an unsaved file" and perhaps make the close X button red, but that's simply not a sufficient solution.

No amount of graphical sugar will remedy this. A warning icon will be equally as inefficient as the red file name highlight. If the relatively large red rectangle does not work, the small yellow triangle hardly will. The data loss is a serious matter and therefore justifies a pop up dialog, the same way closing an unsaved, modified file does.

To kind of reinforce my point, I challenge you to find any other mainstream piece of software out there which has GUI, allows user to create content, save it into files, and does not have an overwrite confirmation pop up dialog. I am pretty sure you will have very hard time finding at least one.

The thing is - Blender already sets the precedent by having a pop up prompt when closing an unsaved file. It's the same type of scenario. One could easily say "Just don't press the window close button if you are not sure you want to close an unsaved file" and perhaps make the close X button red, but that's simply not a sufficient solution. No amount of graphical sugar will remedy this. A warning icon will be equally as inefficient as the red file name highlight. If the relatively large red rectangle does not work, the small yellow triangle hardly will. The data loss is a serious matter and therefore justifies a pop up dialog, the same way closing an unsaved, modified file does. To kind of reinforce my point, I challenge you to find any other mainstream piece of software out there which has GUI, allows user to create content, save it into files, and does not have an overwrite confirmation pop up dialog. I am pretty sure you will have very hard time finding at least one.

Stephen Swaney commented

2021-04-07 20:31:52 +02:00

Added subscriber: @StephenSwaney

Stephen Swaney commented

2021-04-07 20:31:53 +02:00

Unfortunately, when working fast, a warning dialog is the only thing that can save you from this trap.

Even more unfortunately, people become habituated to clicking the Are You Sure? dialog as part of their normal work flow - especially when working fast.

I suggest that in addition to theAre You Sure? dialog, we add a **Are You Really Sure You Are Sure?**dialog as confirmation.

> Unfortunately, when working fast, a warning dialog is the only thing that can save you from this trap. Even more unfortunately, people become habituated to clicking the **Are You Sure?** dialog as part of their normal work flow - especially when working fast. I suggest that in addition to the**Are You Sure?** dialog, we add a **Are You Really Sure You Are Sure?**dialog as confirmation.

Bastien Montagne commented

2021-04-07 20:33:01 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Bastien Montagne closed this issue

2021-04-07 20:33:01 +02:00

Bastien Montagne commented

2021-04-07 20:33:01 +02:00

Thanks for the report, but this is absolutely not a bug, everything is working as expected.

Design discussions on the tracker are strictly restricted to the initiative of active development team members (would be related to #user_interface module, but currently such UI/UX topics are more or less frozen anyway).

Thanks for the report, but this is absolutely not a bug, everything is working as expected. Design discussions on the tracker are strictly restricted to the initiative of active development team members (would be related to #user_interface module, but currently such UI/UX topics are more or less frozen anyway).

Ludvik Koutny commented

2021-04-07 20:35:05 +02:00

In #87265#1142469, @StephenSwaney wrote:

Unfortunately, when working fast, a warning dialog is the only thing that can save you from this trap.

Even more unfortunately, people become habituated to clicking the Are You Sure? dialog as part of their normal work flow - especially when working fast.

I suggest that in addition to theAre You Sure? dialog, we add a **Are You Really Sure You Are Sure?**dialog as confirmation.

This is often solved such that the default active UI element is the preventive one, so that if the dialog pops up and you just press enter, the active UI element is the one that does not overwrite, not the one that does.

I'd personally just suggest that destructive file operations such as overwrite would have the overwrite confirmation button itself displayed in red color. That would be a good indication.

> In #87265#1142469, @StephenSwaney wrote: >> Unfortunately, when working fast, a warning dialog is the only thing that can save you from this trap. > > Even more unfortunately, people become habituated to clicking the **Are You Sure?** dialog as part of their normal work flow - especially when working fast. > > I suggest that in addition to the**Are You Sure?** dialog, we add a **Are You Really Sure You Are Sure?**dialog as confirmation. This is often solved such that the default active UI element is the preventive one, so that if the dialog pops up and you just press enter, the active UI element is the one that does not overwrite, not the one that does. I'd personally just suggest that destructive file operations such as overwrite would have the overwrite confirmation button itself displayed in red color. That would be a good indication.

Ludvik Koutny commented

2021-04-07 20:35:59 +02:00

In #87265#1142470, @mont29 wrote:
Thanks for the report, but this is absolutely not a bug, everything is working as expected.

Design discussions on the tracker are strictly restricted to the initiative of active development team members (would be related to #user_interface module, but currently such UI/UX topics are more or less frozen anyway).

So you are implying that data loss is more or less fine? And Blender should not help the users here, but punish them instead? That's it?

If this is your approach to data loss, then can you explain why this was addressed, even though it was not technically a bug: https://developer.blender.org/T61412 ? This is the exact same class of problem.

> In #87265#1142470, @mont29 wrote: > Thanks for the report, but this is absolutely not a bug, everything is working as expected. > > Design discussions on the tracker are strictly restricted to the initiative of active development team members (would be related to #user_interface module, but currently such UI/UX topics are more or less frozen anyway). So you are implying that data loss is more or less fine? And Blender should not help the users here, but punish them instead? That's it? If this is your approach to data loss, then can you explain why this was addressed, even though it was not technically a bug: https://developer.blender.org/T61412 ? This is the exact same class of problem.

Falk David commented

2021-04-08 10:10:22 +02:00

Added subscriber: @filedescriptor

Falk David commented

2021-04-08 10:10:22 +02:00

@Rawalanche

So you are implying that data loss is more or less fine? And Blender should not help the users here, but punish them instead? That's it?

No, we have rules on the bug tracker. As Bastien has said, this would not classify as a bug because the code is working as intended. So the bug tracker is just not the place to have this discussion. That doesn't mean it's not welcome, it is! Just not here. A better place would be devtalk.

@Rawalanche > So you are implying that data loss is more or less fine? And Blender should not help the users here, but punish them instead? That's it? No, we have rules on the bug tracker. As Bastien has said, this would not classify as a bug because the code is working as intended. So the bug tracker is just not the place to have this discussion. That doesn't mean it's not welcome, it is! Just not here. A better place would be devtalk.

Ludvik Koutny commented

2021-04-08 10:20:25 +02:00

In #87265#1142716, @filedescriptor wrote:
@Rawalanche

So you are implying that data loss is more or less fine? And Blender should not help the users here, but punish them instead? That's it?

No, we have rules on the bug tracker. As Bastien has said, this would not classify as a bug because the code is working as intended. So the bug tracker is just not the place to have this discussion. That doesn't mean it's not welcome, it is! Just not here. A better place would be devtalk.

Every. Single. Time.... I post something like this on devtalk, it ends up ignored with 0 replies. It's not a new shiny sculpt brush, or a new geometry nodes node. It's just a possibility of data loss. No one cares about that.

> In #87265#1142716, @filedescriptor wrote: > @Rawalanche > >> So you are implying that data loss is more or less fine? And Blender should not help the users here, but punish them instead? That's it? > > No, we have rules on the bug tracker. As Bastien has said, this would not classify as a bug because the code is working as intended. So the bug tracker is just not the place to have this discussion. That doesn't mean it's not welcome, it is! Just not here. A better place would be devtalk. Every. Single. Time.... I post something like this on devtalk, it ends up ignored with 0 replies. It's not a new shiny sculpt brush, or a new geometry nodes node. It's just a possibility of data loss. No one cares about that.

Ben-Knight commented

2024-03-18 00:05:27 +01:00

Hey! Not sure where the best place to bump this issue would be, but I feel like this needs to be discussed.

Particularly with how accidentally double clicking a .blend file in the save as menu will almost always result in unintended data loss – in the early days of blender, there was a save overwrite confirmation and you couldn't double click to save in the save-as menu. But over the years, Blender evolved and that consideration got understandably lost somewhere along the way.

Having a confirmation in the save-as menu when trying to save a file with the same name as an already existing file in that folder seems like it would be fairly easy to implement, would prevent many cases of data loss in the future, and bring Blender in line with a majority of other software that already have this behavior.

Hey! Not sure where the best place to bump this issue would be, but I feel like this needs to be discussed. Particularly with how accidentally double clicking a .blend file in the save as menu will almost always result in unintended data loss – [in the early days of blender, there was a save overwrite confirmation and you couldn't double click to save in the save-as menu. ](https://devtalk.blender.org/t/some-of-the-bug-triage-staff-are-very-inexperienced/14718/37?u=ben_knight) But over the years, Blender evolved and that consideration got understandably lost somewhere along the way. Having a confirmation in the save-as menu when trying to save a file with the same name as an already existing file in that folder seems like it would be fairly easy to implement, would prevent many cases of data loss in the future, and bring Blender in line with a majority of other software that already have this behavior.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Lack of file overwrite prompt leads to data loss #87265