Lack of file overwrite prompt can lead to data loss

Yes, great point, and I agree totally you. In this case and overall, in Blender, should think bigger projects, not just one persons personal project. It would be just annoying, if half day work got lost, but in larger projects, where schedule is calculated more specific, it cost a lot.
Having overwrite warning, would be just logical for most computer software users, and there isn’t any sense to make it way how few developers think how it could be. It have seen in many softwares, where developer(s) know how to use software and where things could found, but for daily users there’s so gih learning curve.

1 Like

This really has to be a priority, even i have lost some files.

3 Likes

Heh, yes, most of us has. That’s why this thread exists :slight_smile:

I just wish that this was high on the priority list :roll_eyes:

i don’t understand why important stuff like this tend to be ignored and take ages to be approved/committed while dangerous cosmetic patches are being rushed in without proper reviews :upside_down_face:

As a coder, I would never move files around like that, because you don’t know if the user even has a trash folder, if the disk if full or if there is only temporary access. There are a lot of potential failures here that could happen, which might even crash Blender due to OS restrictions, and then you will still have a data loss.

I don’t really have other comments, about the issue itself, but moving files around behind the user’s back is a big no no.

2 Likes

adding my voice to the choir. blender has a number of warning dialogs to confirm destructive actions like close without saving, deleting with ‘X’, etc, so this isn’t even a blender paradigm, its just plain inconsistency.

make it a user preference if you must, but this is a dangerous oversight that is costing people work.

2 Likes

Sorry to bump the thread again but the issue really has to be addressed.
In the F4 dialog export and import are just above each other and the dialogs look very similar as well. I just ran into the case again, yesterday, where after a day of work I accidentally hit the wrong dialog and saved over an important reference file on the network instead of importing it to the scene.
This is extremely dangerous in a work environment and something that can’t even be considered a papercut or anything any more at this point.

My eternal thanks to anyone who is willing to tackle this as soon as possible. And if only for a temporary fix until the full implementation is decided on.

1 Like

I don’t think this will get addressed until someone really important loses their data and makes waves about it. Some influencer or someone at Blender Studio or something. Until then, we will just have to keep losing our data :frowning:

There’s this general weird feeling when using Blender, compared to most other software, where even if you use it on daily basis for years, you constantly have this uneasy feeling you are just one click away from destroying your work. Not just because of this but also because of the data management / fake user workflow. Using Blender daily feels like your job is defusing bombs, not doing 3D graphics. No matter how long and/or often you use it.

2 Likes

We really can’t continue to ignore super important issues like this one just because it’s not a problem at Blender Studio, yet.
If I was able to code I’d try to give it a shot, somehow. But I’m just a user. Seeing how much Progress Blender is making in all areas and then still having to beg for implementation of functionality that makes Blender safe to use feel weird.

1 Like

And then people joke about “that” Sculpting program when you hit save it creates a screenshot instead of saving your work.

And here we have Blender, going out of it’s way to you make wish you’d use a industry standard software with QOL ideology.

At this point I really don’t care if it’s just a temporary band-aid or duct-tape solution until the final design decision has been made. We are talking about seriously critical data-loss.

(edit) Five days later and it happened again. Please, please, please make it a high priority to do something about this. It is really unprofessional.

2 Likes

Happening to me as well more often than I’d like.

What’s strange to me is the inconsistency - depending on the context I can’t make conscious operations with objects that are hidden, and getting confirmation dialogs when deleting data in the viewport.

On the other hand there’s export, where it literally just overwrites an alembic, no questions asked. I don’t think a confirmation (especially if let’s say optional) would cause as big of an inconvenience than loosing data frequently.

No sure how those decisions are made but I’d imagine it’s happening in a pretty isolated environment.

A few related things. Nothing official of course, just my own wishes and dreams.

The following makes it easier to make much better confirmation dialogs: D10955. We’d be able to define many more of them for all sorts of uses. But then we’d add the ability for users to easily configure them so you could enable/disable whichever ones you wanted or not: T97780. The following proposes Topbar menu changes, including separating “Import” and “Export”: D8706

4 Likes

I love all of these.

Regarding D10955, I think the dialogs should have some internal severity setting, where the severe ones, usually those which decide where some data gets deleted, should not be dismissable by just dragging the mouse cursor out of the bounds. The save dialog already works that way. You can still click outside it to cancel it, but it doesn’t just disappear if you accidentally move your mouse. Dialogs disappearing by just mere mouse movement is one of those long standing crimes against UX blender does to this day.

That is part of the design. There is a Boolean called “movemouse_quit” that is set per dialog. If you apply that patch you will see that most do not dismiss that way.

why not just call the native Windows overwrite dialog?
that would be good enough for me

There might be issues with that on Mac and Linux…

ah too bad
but damn, this issue really should be high prio. losing files like that is a big big problem