Dropbox saving errors with compressed files #93389

New Issue

Daniel Salazar · 2021-11-25T21:41:12+01:00

Daniel Salazar commented

2021-11-25 21:41:12 +01:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.49

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-11-24 23:04, hash: 827c5b399e

Short description of error
Saving compressed blend files on a Dropbox folder gives sporadical saving errors

Exact steps for others to reproduce the error
Save a compressed blend file on a Dropbox folder
If it doesn't give you an error keep pressing Ctrl+S

Notes:
Tested on Windows with the official Dropbox app
Save versioning is completely disabled

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.49 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-11-24 23:04, hash: `827c5b399e` **Short description of error** Saving compressed blend files on a Dropbox folder gives sporadical saving errors ![image.png](https://archive.blender.org/developer/F12192866/image.png) **Exact steps for others to reproduce the error** Save a compressed blend file on a Dropbox folder If it doesn't give you an error keep pressing Ctrl+S *Notes:* *Tested on Windows with the official Dropbox app* *Save versioning is completely disabled*

Daniel Salazar commented

2021-11-25 21:41:12 +01:00

Added subscriber: @zanqdo

Carlos Muñoz commented

2021-11-26 00:39:40 +01:00

Added subscriber: @carlosmu

Carlos Muñoz commented

2021-11-26 00:39:40 +01:00

Yes, the same thing happened to me.
Anyway... Dropbox is usually troublesome.

Yes, the same thing happened to me. Anyway... Dropbox is usually troublesome. ![imagen.png](https://archive.blender.org/developer/F12203715/imagen.png)

Carlos Muñoz commented

2021-11-26 00:44:01 +01:00

If you pause the sync in Dropbox the issue disappears.
Apparently the conflict is because Dropbox takes control of the file.

If you pause the sync in Dropbox the issue disappears. Apparently the conflict is because Dropbox takes control of the file.

Richard Antalik commented

2021-11-26 07:24:13 +01:00

Added subscribers: @Harley, @iss

Richard Antalik commented

2021-11-26 07:24:13 +01:00

@Harley Saw you discussed this on chat, but it seems you haven't come to conclusion where the problem is? Just wanted to make sure all info is here too.

Harley Acheson commented

2021-11-26 17:50:41 +01:00

When we save we first save the document in the target location with a temporary name. If that is successful we then rename this to the final desired name. This is a fairly standard practice that works as a failsafe for quite a few hardware, connectivity, and permissions errors.

In this case though Dropbox notices the new (temp) file has been added and starts processes that lock it for a short time which doesn’t allow the rename to proceed. That it is more likely to happen with compressed blends could be that these take a bit longer to save, or they might be saved incrementally, triggering Dropbox to do its thing at a different time.

Not sure (yet) what we can do about this. A good start would be a way to know these files are in Dropbox, ideally in a generic way that would work for similar systems and does not require their API. We can tell if the items are offline (not currently local) as we use that knowledge to no allow thumbnail creation, but not if the are just regular local files.

One thing that would solve this situation is to initially save the temp file in the user’s temp folder and the rename from there to final path. Rename doesn’t care if the folders, or even drives, differ so acts as a “move”. Although it would fix this issue it would have downsides. There would be performance degradation when saving any file to a drive that differs from the one containing your temp folder. And this would also negate some of the usefulness of the two-step save process since this doesn’t test the writeability of the target location until the rename.

When we save we first save the document in the target location with a temporary name. If that is successful we then rename this to the final desired name. This is a fairly standard practice that works as a failsafe for quite a few hardware, connectivity, and permissions errors. In this case though Dropbox notices the new (temp) file has been added and starts processes that lock it for a short time which doesn’t allow the rename to proceed. That it is more likely to happen with compressed blends could be that these take a bit longer to save, or they might be saved incrementally, triggering Dropbox to do its thing at a different time. Not sure (yet) what we can do about this. A good start would be a way to know these files are in Dropbox, ideally in a generic way that would work for similar systems and does not require their API. We can tell if the items are offline (not currently local) as we use that knowledge to no allow thumbnail creation, but not if the are just regular local files. One thing that would solve this situation is to initially save the temp file in the user’s temp folder and the rename from there to final path. Rename doesn’t care if the folders, or even drives, differ so acts as a “move”. Although it would fix this issue it would have downsides. There would be performance degradation when saving any file to a drive that differs from the one containing your temp folder. And this would also negate some of the usefulness of the two-step save process since this doesn’t test the writeability of the target location until the rename.

Brecht Van Lommel commented

2021-11-26 18:09:45 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2021-11-26 18:09:45 +01:00

Here's some background on a similar thing in Sublime text, where they ended up disabling atomic saves.
https://stackoverflow.com/questions/20634684/what-is-sublime-text-doing-when-i-save-a-file

Also for the case where you write a temp file on another drive, it's not obvious that rename/move is atomic.

The ideal solution is not obvious to me. It feels like this should be a solved problem in other applications, but it seems hard to find good information on this.

Here's some background on a similar thing in Sublime text, where they ended up disabling atomic saves. https://stackoverflow.com/questions/20634684/what-is-sublime-text-doing-when-i-save-a-file Also for the case where you write a temp file on another drive, it's not obvious that rename/move is atomic. The ideal solution is not obvious to me. It feels like this should be a solved problem in other applications, but it seems hard to find good information on this.

Harley Acheson commented

2021-11-26 18:17:03 +01:00

Gimp has reported almost-identical errors, but not seeing resolution:

Wondering now about the idea of first saving to user temp folder only if on the same drive as target location.

Gimp has reported almost-identical errors, but not seeing resolution: - https://gitlab.gnome.org/GNOME/gimp/-/issues/6495 - https://gitlab.gnome.org/GNOME/gimp/-/issues/5212 - https://gitlab.gnome.org/GNOME/gimp/-/issues/1370 Wondering now about the idea of first saving to user temp folder **only if** on the same drive as target location.

Raimund Klink commented

2021-11-29 10:46:10 +01:00

Added subscriber: @Raimund58

Raimund Klink commented

2021-11-29 10:46:10 +01:00

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

Raimund Klink commented

2021-11-29 10:46:10 +01:00

I think this task should be marked as confirmed.

Daniel Salazar commented

2023-02-02 19:51:57 +01:00

Dropping to say I've re-enabled compression to test things for a few days now (Windows and Linux) and I've gotten no errors so far. Maybe Dropbox fixed something or the new compression algorithm in Blender works better?

Can anyone else test?

Dropping to say I've re-enabled compression to test things for a few days now (Windows and Linux) and I've gotten no errors so far. Maybe Dropbox fixed something or the new compression algorithm in Blender works better? Can anyone else test?

Bastien Montagne added this to the Core project 2023-02-09 15:42:54 +01:00

Bastien Montagne removed this from the Core project 2023-02-09 18:20:37 +01:00

Pratik Borhade referenced this issue

2024-09-09 07:42:31 +02:00

Can't save file, file saved with "@" #127303

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

Dropbox saving errors with compressed files #93389