Found in Blender 2.57b on WinXP x32
Let's assume that the storage device is already quite full. If you have saved a .blend to that device and run e.g. a smoke sim or perform any other task filling up the storage space and then try to save the changed Blender file using Save/Ctrl-S/Ctrl-W, the .blend file is renamed to .blend1 but the current state of the file is not saved because there is no space left for it. When using Save from the File menu, there is no warning (in contrast to using Ctrl-W/Ctrl-S - they don't save the current state, too and you loose the .blend but at least there is a storage space warning).
If that happened only .blend1 and .blend2 are left on the device. Now if you try to save a fresh .blend file to replace the one that has just been eliminated using Save As/Save(since the path is still there), the .blend2 is being erased and .blend1 is renamed to .blend2.
- if there is a .blend it will vanish (renamed to .blend1 without space for a new .blend) - unsaved progress is lost (if quit.blend is written to the same device)
- if there is a .blend1 or .blend2, a .blend will be created but .blend1 is gone (renamed to .blend2 without space for a new .blend1)
It's also interesting to see what happens if the quit.blend is written to the same cramped device: it is always created, even at 0kB if no space is left (e.g. quit.blend of a 673kB Blender file was 10kB, there were only 35kB left on the device). But if you try to open that quit.blend (by double-clicking), Blender crashes. If dragged to an open instance of Blender it does not crash but print this message to the console: 'Error: Loading E:\quit.blend failed: Failed to read blend file: "E:\quit.blend", incomplete'
Other cases of Blender writing to a full storage device:
- AutoSave seems to leave everything intact, printing 'Error: No space left on device' to the console, writing nothing to disk.
- Saving As a new file also works well, displaying the 'Error: No space left on device' message, writing nothing to disk.
- Saving an image even gives 2 warnings: in the gui 'Couldn't write image E:\\untitled.bmp' and one in the console: 'E:\\untitled.bmp: No space left on device'. Nonetheless it's trying to write the file but it can't be opened. The file can't even be deleted while Blender is still running (file in use).
- Rendering an animation [png sequence] prints an error to the console, but it creates an incomplete file (even at 0kB) that can't be deleted while Blender is still running (file in use)
- Rendering an animation [Avi Codec] continues to the last frame although disk capacity it at zero. No error is displayed but the video can't be played
- Rendering an animation [OggTheora Codec] aborts the rendering with console and gui error messages, the video can be played (at least in VLC).
In some of these cases, I got irreproducible 'Error: Not freed memory blocks:' errors when closing Blender.
Found in Blender 2.57b on WinXP x32
- To Do
Let's disregard all point caches and other cache saves, these are probably not protected well (and can be noted as a todo).
In the 90ies (small hard drives :) we suffered full disks all the time, so I coded a well working protection for it. I always presumed it worked fine still, but reviewing code I noticed the feature now fails by a cleanup of code.
This is how secure .blend saving works (is meant to work):
1) saving a file.blend actually saves a new file, called file.blend@
2) if that save was succesful (so there's space on drive)
- do reverse file history (move .blend1 -> .blend2, .blend -> .blend1)
- rename .blend@ to .blend
3) otherwise remove .blend@ and throw up "disk full" error.
Step 2) is fully safe, even when another application is also writing to the disk at the same time.
The quit.blend is actually not a .blend file save, but a dump of our undo buffer :) That could get a check too of course.
Fixed svn rev. 37098
Moved the do_history into the BLO_write_file, so the file renaming happens
after successful write of the temporary .blend@ file. as described by Ton.
Marked as closed/todo for someone else to eventually pick up.
* writing animations and images
* point caches and other cache saves