Currently, and always, in Blender, zero-user datablocks without a fake user are not saved when saving a .blend file, so the next time that .blend file is re-openedFully deleting datablocks from a blend doesn't happen as easily as most users might expect, such datablocks are gone without any way to recover thembecause "delete" is often used when "un-link" is what is actually meant. The same can also be achieved with the Purge Orphans operator,This can cause a lot of confusion and uncertainty during production. so no reloadingProper deletion of the .blend file is necessary.datablocks requires that they are first un-linked, The Purge operator recently got a much needed "then they can be purged via File->Clean Up->Recursive" option,e Unused Datablocks. which I find extremely useful;This works beautifully, Withand I would like to propose adding an option to have this operation enabled,executed before a file save. not only will it purge zero-user datablocksI would even go as far as to suggest making this the default, but also datablocks whose only users were zero-user datablocksthat can be its own discussion.
This behaviour works great for cleaning up a .blend file after deleting complex elements like an entire character, and **I propose having this behaviour available also for saving files**. Personally, I would make this the default, but I know that could be controversial, so having it be an option that is disabled by default would still be welcome.
### Use case, sort of### Use case
Not only would this make perfect sense according to everyone I've talked to so far (@sybren @mont29 @Severin @simonthommes ) but also help us keep clean scenes during production. Currently, this can very easily happen:
- Animator duplicates an overridden character. All its objects get a .001 suffix.
- Animator deletes that copy, saves their file, and later re-opens it. Only one "layer" of unused objects has been cleaned, so there can still be orphan object datablocks lying around unseen.
- Animator duplicates the character again. Now the number suffix of their objects are all over the place. Some of them have .001 and others have .002.
As they continue working and duplicating characters, the old, unused objects slowly get deleted, and the name suffixes really get all over the place. It's not nice to get your objects names all mixed up like this, as things get really confusing when trying to troubleshoot problems in a production file, since everywhere where one object references another, the mismatching suffixes give the troubleshooter anxiety and uncertainty. The only way to avoid this currently is to tell the entire production team to always run a recursive Purge after deleting anything, which is very error-prone.
### Potential issues
- ~~The current recursive purge purges Text datablocks, which is bad because they don't have the possibility of a "Fake User", so they should be excluded (or better yet, be included in the "fake user" system, and get a fake user by default). (T87489~~ (Fixed by D10983)
- Actions still don't have fake user enabled by default, which,. as someone who's job it is to listen to animators complain about Blender all day,The long standing issue of Action datablocks "disappearing" on users and making them lose hours of work if they forget to click Fake User would be exacerbated by this change. I think iThis could be trivially fixed by giving Actions a massive blunder.fake user on creation, This long standing issue of Action datablocks "disappearing" on users and making them lose hours of work if they forget to click Fake User will be exacerbated by this changeand forcing users to clean up their unused Actions themselves.