In T61209#1080029, @Brecht Van Lommel (brecht) wrote:

Please treat it with the same kind of respect as would be expected when walking into an office where developers are working.

Sure. I am also addons developer, and know how hard this work is and how concentration is important.
But, please, be careful with workflow design, otherwise you will completely push us out of production.

Design process in a nutshell, pretty accurate.
Over the course of several iterations, when important data becomes garbage and garbage becomes important at any moment, sooner or later there comes a point when it simply cannot be taken care of, especially at deadlines.
Projects cleanliness in business always has a lower priority than results (because results are paid for), and this is a problem of the entire industry.

This whole proposal looks strange. It looks like you are trying to design a part of the engine without considering the whole engine.

I think it's like turning an automatic transmission into a manual.
The manual purge solution is familiar from the Autodesk family of products and all of their longstanding problems.

As I understood it's because with new Asset Browser we need to store for example unused material with it nodes and not be purged after close blender.

Asset Browser allows you to simply view some data, and that's it, its presence cannot affect the saving of unused data in the file.

Just checked, and indeed when we mark asset it become a fake user, so why need to store all trash data? - unclear.

It is logical when we mark something as an asset in library file, because this way we confirm that we need it.

I wan to try to clarify the issue about auto/manual purge and garbage collector.

The problem is that users purges or optimizes any kind of things only when the situation turns critical - for example, when HDD is full.
This is suitable load for regular users (like, for example, freelancers), but is not suitable for companies, which generates a lot of files during production.

This is the same problem we faced in AutoCAD - whose DWG files can also store unused datablocks, but where only manual cleanup is provided.
Situation became critical only when corporate hard drives are full, that means that there way more data to purge and cleanup.
So Autodesk provided free application with the ability to batch purge process, but it rewrites all the purged files to a specified version.
Since different versions of AutoCAD contain different subset of features, and earlier versions contain features which was cut out, batch purge is not a suitable solution, especially if to take into account that there are tens of thousands files are generated during corporative production.

The situation is complicated by the fact that, unlike DWG files, which usually weigh 10-20 megabytes per file, blend files weigh can easily reach gigabytes, and the amount of unused data can also reach gigabytes per file, what wastes hard drive space extremely fast, and which is especially critical at the corporate level. Also, the size of file hides the amount of unused datablocks it contains, so it is hard to say if computer you work is able to open such a file, having just information about its size, turning files into black boxes. Such an issue is presented, for example, in 3dsmax, which have the ability to save larger files than it can actually open later on the same computer.

So I want to clarify, that proper autopack, autopurge and automatic garbage collector systems design (like any other massive data management solutions during production lifecycle) is a corporate level requirement.

working in archicad i used to resave files due to garbage it collects. It is cruel thing. Every half a year 10 gb files needed to be rewrited completely on teamwork.
I don't want the same in blender.
My blender pipeline has some custom purge buttons that clear user-free data. So i not need check if node tree not used. i just clean it once. I know what i utilize and fakeusering it directly.

There is a huge and massive indistry level problem - project files congestion issue.
And the problem is that Blender system realization is the only solution on a market that solves that issue in practice.

Yes, it has "issues", but in fact they are just the only way that works.

It is quite typical project management case.

Person A: writes unused id's into project file.
Person B: open project file, make some changes - puts and replaces heavyweight assets according to design changes, purges unused data because file became too heavy.
Person A: "where is my data, I saved it into the file, it was important"
Person B: "there was some unused data, so I purged it to be able to work with project file, so I am not even sorry"

There are two solutions after such a situation occurs - always lose unused id data as a rule for everybody or never purge anything ever again until project is not finished. The first solution is current b3d behavior, the second one or any other are not possible during production.

Multiple fake users will require lots of unnecesarry additional management at the cost of lack of a solution to the original problems - project files congestion issue and using unused id's trash bin by different persons for mixing trash with no trash.

If some data was marked as a fake user, that means that some user already put some attention to mark it to preserve it - this is the most important part.

Of course, it is possible to give a names to a fake users, but after the point trash was marked, it is not a trash for automating deletion anymore.

Of course, no one will tell what was "Ralph" or "Important" or "Important1111" fake users about after a month of project making - because fake usered unused data is a dynamic context data which is hard to label by definition, since it is a self-representative data type (where the context is represented by data itself) which cannot be described properly by names.

I also think that autofaking unused data is a bad idea, because when people tag a fake user, they separate the trash that needs to be lost from the important data that needs to be preserved.
Doing this manually is the only correct way, otherwise it will be difficult later to sort and clean up the autofaked data.

Thanks for the feedbacks, updated design proposal. Note that this is still in discussion phase, not yet finalized and approved.

In T61209#1119450, @Eugene Du (APEC) wrote:

Just checked, and indeed when we mark asset it become a fake user, so why need to store all trash data? - unclear.

In T61209#1236390, @Даниил (Daniel_kluev) wrote:

Doing this manually is the only correct way, otherwise it will be difficult later to sort and clean up the autofaked data.

That is the original question: defining what is "trash".

I do agree with @Даниил (Daniel_kluev)
for the moment i don't think there is a clear vision of how to filter the garbage from the work (more than 3 years of comments...): this division is the result of work dynamics external to the software and must be used human intelligence.

Maybe then the problem shifts: the solution is to find the best method to assist the human to be able to delete, as quickly as possible, what he considers to be junk.

Thank you,
Riccardo

I suggest a pop-up warning when confirming a deletion, to make sure users know what they're deleting. By name when it's a few things, and just the number of things if it's a lot of things (eg. when deleting a collection and all its contents).

If the "Delete" buttons would actually delete things instead of unlinking them, the problem that sparked T87490 would be sidestepped, which is super nice. That means that this proposal would solve T87490 even without the extra option to purge on file save. 👍

In T61209#1245089, @Demeter Dzadik (Mets) wrote:

I suggest a pop-up warning when confirming a deletion, to make sure users know what they're deleting. By name when it's a few things, and just the number of things if it's a lot of things (eg. when deleting a collection and all its contents).

If the "Delete" buttons would actually delete things instead of unlinking them, the problem that sparked T87490 would be sidestepped, which is super nice. That means that this proposal would solve T87490 even without the extra option to purge on file save. 👍

The last thing Blender needs is more deletion confirmation pop ups (aside from file management). There should be one simple rule enforced. Deletion confirmation popup should exist ONLY for operations which are not supported by undo. That's it. Datablock deletion can be usually undone. Overwriting a file can not be undone, so pop up is warranted there. Deletion of a material can, so a pop up doesn't belong there.

Regarding the overall topic. In my opinion, most datablock types should never ever be auto-deleted, except a very few exceptions, such as mesh datablocks. And the fake user thing should be completely removed.

The reason this mess exists is that unlike other common 3D software, Blender does not have any proper, easy to use place for scene data management. The closest to it is Outliner in the "Blend File" mode. The problem with this solution is that it only allows datablock inspection and deletion, not creation. In other common 3D software, you'd expect to have some sort of space where you can for example both create and delete (not unlink, actually delete) materials in your file, as well as assign them to objects. In Blender, you create material data blocks in this weird, confusing datablock UI element, which you can also unlink them from, but you have to delete them in a completely different place. You also have to visit this completely different place for mas management of multiple datablocks.

I think game engines, such as Unreal, Unity, Godot and so on are a great example of how a data management should work. There should be some asset browser mode, which instead of browsing the asset library would also allow you to browse your active Blend file, and offer complete datablock functionality - creating, renaming, editing, assigning, and deleting, all in one place. This would allow for following:

• Removal of fake user workflow
• Removal of any worry of unintended data loss
• Removal of the whole purge data concept
• Removal of messy scenes with many unused fake user datablocks caused by blender not having good tools that would encourage users to care and manage the data stored in their scene files

Unfortunately, addressing this in a way I just described would require bigger changes, because it would open an ugly can of worms of bad legacy design in parts of Blender. For example the fact that material editing is almost exclusively tied to viewport object selection (except the hacky operator to "pin" current material). It would require more fundamental redesign of some concepts, so that you could for example edit materials in material editor regardless of what you have selected. And material assignment would be completely decoupled from material editing.

But I think this would be actually helpful in the end. I mean how many of us got frustrated when we accidentally changed material assigned to our object when we switched the active material in the shader editor and forgot it's tied to the active material slot on the active selected object :) It's not a good design.

In T61209#1245135, @Ludvik Koutny (rawalanche) wrote:

And the fake user thing should be completely removed.

This is a solution suitable for 3dsmax, Maya, C4D and other software which does not have the ability to pack media into a file yet.

And material assignment would be completely decoupled from material editing.

This will require material id, multimaterial or other legacy 3dsmax solutions that Blender managed to avoid.

In T61209#1245135, @Ludvik Koutny (rawalanche) wrote:

In T61209#1245089, @Demeter Dzadik (Mets) wrote:

The reason this mess exists is that unlike other common 3D software, Blender does not have any proper, easy to use place for scene data management.

This looks like a system from 3dsmax, where Nodes editor was put on top of Slots editor, so, unlike in Blender it wasnt designed for flexible material editing.
In 3dsmax in complex scenes you have to clean your slots and pick materials from objects, so it is object-oriented anyway.

And it is very difficult for a beginner to set up 3d max materials, in Blender it is much easier to figure it out.

In T61209#1245230, @Paul Kotelevets (1D_Inc) wrote:

In T61209#1245135, @Ludvik Koutny (rawalanche) wrote:

And the fake user thing should be completely removed.

This is a solution suitable for 3dsmax, Maya, C4D and other software which does not have the ability to pack media into a file yet.

And material assignment would be completely decoupled from material editing.

This will require material id, multimaterial or other legacy 3dsmax solutions that Blender managed to avoid.

Please - not just here, but anywhere where both I and you post - just please do not respond to my posts. You never ever do mental work to figure out what I wrote, and just start spewing nonsense.

You did not even read my post, otherwise you wouldn't write what you wrote. I mentioned game engines as a great example of data management. Game engines usually have some sort of project the data is contained within, both internally, and externally. Blender does the exact same thing, with the only exception that the blend file is an internal folder structure archive which can not be browsed using OS file explorer. That's about it. When you look at most of the game engines, their architecture is quite similar to Blender, with the only exception that unlike Bledner, they have much better tools for managing these "datablocks", generally in form of some content browser, which allows you to create them, edit them and delete them from a single place. There is no such thing multisubobject material, and neither does it have to be in Blender.

The decoupling of material editing from object selection would not change much about the way materials are used on objects in Blender. You could still create material slots on objects exactly the same way you do now, and assign materials to them again in the exactly same way as you do now. The only difference would be that if you changed the active material in the shader editor, it would NOT change the material assigned to the currently active material slot on the object. You could optionally lock them together (in the same way you can sync UV editor selection to 3D view selection), to behave like they do now, but it would not be default.

This could then allow more comfortable workflows, such as that you could drag and drop material from any object material slot onto the shader editor and it would become the active material in the shader editor, and you could drag and drop any material from shader editor onto existing object material slot to assign it. Of course you could still also assign materials to material slots on objects by using the search datablock button, and you could do the same for the shader editor. It's just that these two would not be tied together.

Here's a great example of this ridiculousness: Sometimes I have some materials in the scene that I need to be there for later use, but they are not assigned to any material slot of any object. To be able to edit that material, I first need to create some dummy object in the scene, like a cube, then assign that material to that cube, and only then I can actually use a material editor to edit it. And then delete the temporary cube once I am done. That's just preposterous.

On top of that, this concept is not anything new to Blender. For example, in Image Editor, when you select image to view or edit, you are not actually assigning that image to any selected object, you can just edit it regardless of what's selected in viewport, and the [X] unlink button in the datablock UI element just "clears" it from the image editor, but does not actually remove its assignment from any object or material. See? That's already possible in Blender without a need to haven any sort of "multisub image map". I am proposing that the other editors used for editing datablocks work the same way. So that there is one, unified way of editing datablocks, which allows you to edit any datablock you want, whenever you want it.

Well, unlike image, which can be used as texture or a brush, material has the only one possible host - an object.
Editing shader without connection to object means editing shader without a response in 3dviewport.

In T61209#1245135, @Ludvik Koutny (rawalanche) wrote:

In T61209#1245089, @Demeter Dzadik (Mets) wrote:

I suggest a pop-up warning when confirming a deletion, to make sure users know what they're deleting. By name when it's a few things, and just the number of things if it's a lot of things (eg. when deleting a collection and all its contents).

Datablock deletion can be usually undone.

I was unclear, I was talking about indirect deletions. If you delete an object, you would sometimes delete the object data along with it, but sometimes not, depending on whether that object data is used by anything else. This is when I think a pop-up should be shown to make sure the user realizes they are deleting things other than what they have selected (which would be the case under the current proposal).

In T61209#1245621, @Demeter Dzadik (Mets) wrote:

In T61209#1245135, @Ludvik Koutny (rawalanche) wrote:

In T61209#1245089, @Demeter Dzadik (Mets) wrote:

I suggest a pop-up warning when confirming a deletion, to make sure users know what they're deleting. By name when it's a few things, and just the number of things if it's a lot of things (eg. when deleting a collection and all its contents).

Datablock deletion can be usually undone.

I was unclear, I was talking about indirect deletions. If you delete an object, you would sometimes delete the object data along with it, but sometimes not, depending on whether that object data is used by anything else. This is when I think a pop-up should be shown to make sure the user realizes they are deleting things other than what they have selected (which would be the case under the current proposal).

Cascade delete is very, very dangerous.
At the beginning of this very log thread it was suggested that only some data type should be cascade deleted:
there is no rationality about deciding which (ex. mesh, materials, actions, ecc...).

A pop-up can't work with bulk delete or big project management (where you have a list of 75 pop-up you can't really control what you are deleting...).
RG

In T61209#1245828, @Riccardo Gagliarducci (rickyx) wrote:

A pop-up can't work with bulk delete or big project management

It already exists in some sense. I'm just cleaning up the Sprite Fright production files, and the "Recursive Purge Unused Datablocks" operator gives me a number of each datablock type that will be deleted. Of course at very high numbers it becomes pretty meaningless, but even just seeing the datablock types is very reassuring. For example if I just deleted some static meshes and the pop-up tells me I'm about to delete 3 Actions, I may get suspicious, and not go ahead with the deletion until I double-check what those Actions are exactly.

There may be more robust solutions of course, but I think this would be a good start that could be easy to implement.

In T61209#1245888, @Demeter Dzadik (Mets) wrote:

In T61209#1245828, @Riccardo Gagliarducci (rickyx) wrote:

A pop-up can't work with bulk delete or big project management

For example if I just deleted some static meshes and the pop-up tells me I'm about to delete 3 Actions, I may get suspicious, and not go ahead with the deletion until I double-check what those Actions are exactly.

I am not sure how it is possible to check Actions of a deleted host, but I agree that that there is a strong psychological aspect here.

Such an issue is related, for examples, to stock trading - everybody want to earn 100 usd, but if rules are a bit different - you will get the same 100 usd and stock will get 300, lots of people refuses to do that.
The problem occures when you know, that you will sort of lose 300 usd.

Clearing a music library, for example, is incredibly difficult because you have to define that you will never listen from it and lose it.
People naturally don't like to see they are losing something even more than actually losing it.

There may be more robust solutions of course, but I think this would be a good start that could be easy to implement.

We are trying to figure it out for quite a decade, but it is really hard.
There are known realizations from other software that are more pleasant to use, but in fact are quite useless in practice and does not solve the original problem of a massive project files congestion.

Maybe add a check box when saving your blend file.

When unchecked Orphan Data is deleted.

When checked Orphan Data is saved.

The saved Orphan Data defaults to Fake User.

For team collaborations, we could add the ability to name Orphan Data saves to help prevent team members from accidentally purging each other's saved Orphan Data.

Or choose from already saved Orphan Data from a list.

This saved Orphan Data can be purged at any time from the Edit Menu. You can choose which saved Orphan Data to purge.

The above is pretty much for the first time you save the blend file or do a Save As.

Perhaps include a warning prompt on interim saves if new unsaved Orphan Data was created.

It was already discussed, things doesnot work like that.
If someone set save option he doesnot purge trash, drowning the project files also making trash untouchable, and if someone set purge option, he corrupt files shredding data which was expected to be saved by the other project member.
This system design level problem is not solvable by setup.

What if orphan data will be saved in separate file.
And, if loading main *.blend file without this orphan data file, there will be message - "Orphan data file is missing. Load blend file with purged orphan data?" (like a missing textures).
After loading blend file without orphan data file - it will match a blend file after manually purge and save.

100 project files will generate 200 total files.
Every version increment will have corresponding copy.
Too much to maintain.

It already create 2 files: *.blend and *.blend1
Let it save orphan data to blend1 instead main file

.blend1 files are backups, nothing to do with this.

https://devtalk.blender.org/t/blender-deleted-my-un-assigned-materials-how-is-that-a-feature-fake-user/22715/8
Just wanted to redirect this discussion there
and to be sure @Paul Kotelevets (1D_Inc) read this topic and explained to users why it does not work in team.

In T61209#1298314, @Paul Kotelevets (1D_Inc) wrote:

This system design level problem is not solvable by setup.

Why so?

The concept provided by @BC (ChinoD), in my opinion, is almost perfect.
The only thing missing is set your default user name somewhere in preferences (when working with team) and when saving, use this name for fake user.
If other team member (with its own user name) wanted to purge orphan data it purge only data with his user name or (if the user name was by default and not changed "Fake User") purges also data with "Fake User".
To delete all users orphan data you need to hold shift+click purge button and it ask "Are you sure you want to delete all users orphan data?" - "Yes" - "Cancel"

Example how to add a custom user with it prefs:

In T61209#1302913, @Eugene Du (APEC) wrote:

In T61209#1298314, @Paul Kotelevets (1D_Inc) wrote:

This system design level problem is not solvable by setup.

Why so?

The concept provided by @BC (ChinoD), in my opinion, is almost perfect.
The only thing missing is set your default user name somewhere in preferences (when working with team) and when saving, use this name for fake user.
If other team member (with its own user name) wanted to purge orphan data it purge only data with his user name or (if the user name was by default and not changed "Fake User") purges also data with "Fake User".
To delete all users orphan data you need to hold shift+click purge button and it ask "Are you sure you want to delete all users orphan data?" - "Yes" - "Cancel"

Example how to add a custom user with it prefs:

This will add massive burden of configuration on the users but won't solve much. The main issue is that Blender right now does not have a good editor for datablock management. This alone won't address that.

@Harley Acheson (harley) recently submitted this D14030 UI WIP: User-Managed Unused Data

In T61209#1302896, @Eugene Du (APEC) wrote:

https://devtalk.blender.org/t/blender-deleted-my-un-assigned-materials-how-is-that-a-feature-fake-user/22715/8
Just wanted to redirect this discussion there
and to be sure @Paul Kotelevets (1D_Inc) read this topic and explained to users why it does not work in team.

It was also redirected here, as far as I remember.

Naming (labeling) unused data was also discussed there. Autolabeled trash is untouchable, has no expiration date, and also unmanageable the same way as regular autosaving. I can pack whatever I want no matter how it is needed, and autolabeling will keep it forever. If someone will have to purge it, he will have to take responsibility for all the consequences.

Flexible setup provokes conflicts.
If someone set save all option he doesnot purge trash, drowning the project files also making trash untouchable - if someone set even partial purge option, he will corrupt files shredding data which was expected to be saved by the other project member. If you will send file to Steve, you will lose materials, if you will send file to Jennifer, you will lose textures. Or something else. Or everything. Or not.

There should be a simple rule for everyone compatible with massive production.

After looking at @Eugene Du (APEC)'s mockup, why not have a checkbox in the Preferences that allows to Auto-Save Orphan Data? A singular checkbox. Checked, It saves all Orphan Data. Unchecked it doesn't save Orphan Data. Keep the Fake User as is, shield toggles and all, but have the Auto-Save Orphan Data checkbox checked by default. This would prevent new Users from accidentally losing their work and at the same time allow experienced Users to uncheck the checkbox and go about saving their work with the Fake User method, business as usual. If you work on a Team that requires careful data management then you can require your artists to uncheck the Auto-Save Orphan Data checkbox.

While the Auto-Save Orphan Data checkbox is checked all the Shield Icons will automatically show checked and be grayed out and un-toggleable.

If with the Auto-Save Orphan Data the file becomes bloated, the Artist can purge the unwanted data. The Orphan Data Area of the Outliner could have checkboxes next to each of the Orphan Data. The checked checkboxes are the items that are Purged on click of the Purge Button. The unchecked Items are not Purged.

EDIT: *Maybe the checkboxes in the Orphan Data Area of the Outliner aren't even necessary. An Artist who was using the Auto-Save Orphan Data could simply uncheck it in the Preferences and then manually manage the Orphan Data by un-toggling the Shield icon next to each item they want to Purge in the Orphan Data Area of the Outliner then click the Purge Button.*

The idea is that as long as the Auto-Save Orphan Data checkbox is checked in the Preferences no Orphan Data will be purged unless done manually. If the Auto-Save Orphan Data checkbox is unchecked in the Preferences all Orphan Data that is not assigned to a Fake User is Purged as it works currently.

Because of the same teamwork issue.

As soon as you have any Autosave Orphan data option you will be forced to enable it permanently in order to make sure that you will not lose any data in files from your colleagues or in any file downloaded from the internet.
It doesnot matter how much trash was accidently packed there - it will indeed stay forever, since the only way to split trash from non-trash in unused data is to contact the author and clarify this personally.
As a result, any Autosave Orphan data option is a channel to deliver and spread random trash across Blender ecosystem which is currently cleared automatically. A kind of analogue of the destruction of the dam.

In T61209#1303663, @Даниил (Daniel_kluev) wrote:

As a result, any Autosave Orphan data option is a channel to deliver and spread random trash across Blender ecosystem which is currently cleared automatically. A kind of analogue of the destruction of the dam.

I agree that in case if there will be an option, there will be no actual choice.

At the moment the rule is quite simple and uniform - you "Lose Unused", so anything unused is equalized to trash.
This rule does a lot to protect against trash flooding which is essential for project management.
For sure, we lost a couple of materials a decade ago, because in Blender this rule is presented to a user in an incredibly harsh form - you have to completely unexpectedly lose some data in order to discover this rule.
But we are not very concerned about this couple of materials now, when tens of particle systems, hundreds of textures and thousands of materials are iterating in our projects leaving no trash at all, even when using autopacking, no matter how much members are involved into projects.

There should at least be a warning when closing Blender.

Clicking Manage Data opens a window as @Harley Acheson (harley) setup in D14030. The only change I suggest for the Orphan Data is to display a Shield next to the item type to identify when there are items without a user in the list tree.

This at least offers an opportunity to examine the data and assign a Fake Use before it gets purged.

I agree about warning - it will be nice to make it optional, but turned on by default. Warning will not explain the reason though, but it will make the system at least explicit.

The idea I got (and it has changed over time thanks to the many reflections you have shared) is that:

• the user needs to be clear about Blender's autopurge mechanism for unused blocks. The current one it's a decent and balanced way to handle garbage and offers a nice little error tolerance (one "layer" of data is deleted at a time e.g. if I delete a mesh with a material with a texture, to lose everything I have to save 3 times...).
• there must be a way to manage the project data massively, surely highlighting the various links. The Clean up menu is definitely too simplistic.

That said, the artists should take care of keeping the files in order, and the managers should be responsible for managing the files and the data, possibly even deleting them...
No algorithm can replace this process that comes from contact with the artists and the overall vision of the project.
Thank you.

I feel like I have to clarify what orphan data is and stands for.

In 3dsmax, when you delete a cube - it disappears. Immediately.
In AutoCAD, when you delete a line - it disappears. Immediately.
In Inkscape, when you delete a circle - it disappears. Immediately.
In Photoshop, when you delete a layer - it disappears. Immediately.
In Blender, when you delete a cone - it disappears but not immediately. It goes to a temporal trash bin which is called Orphan data.

Historical reason for this behavior was that it used to be pretty impossible to properly delete an ID while Blender was running, and that undoing such deletion was impossible.

No-user-data which is collected by Orphan data is originally a "data already deleted by user" with the only difference that in Blender it is deleted in some sort of delayed slow motion, just after saving file,
so user is able to explore such a trash bin for some purpose (like fakeusing interesting datablocks) and not immediately lose it like in other programs. Quite a feature.
But when people create some no user data (because they are able to), they are creating data in-between this slow motion deletion and predictably (but not obviously) lose it after saving file.

From this point of view this warning shows weird "a data already deleted by you will be lost" message.
Also "Always write unused IDs on save" task is quite similar to "never lose already deleted data".

Clear: this "slow motions" allows some very nice workflow.
In Blender you can relink data on the fly and the data association mechanism is explicit (duplicate linked...): this is a key differentiation!

Here are a few examples among many...

In any software, when you delete the object it is strightly doomed.
When the trigger is pressed, the bullet is shot and hits the target immediately.

In Blender, when you delete the object, it is sentenced to be doomed.
The trigger is pressed, the bullet is shot, but the target is hit only at the moment when file is saved, executing the sentence written in orphan data, so you have time to make important decisions. It was made because of a programming limitations and became a feature even before Matrix.

In short, this tread looks like an attempt to make bullets never hit targets, because some illegal but possible activity in that bullet time cause quite predictable problems.

So I've read this whole thread and indeed I can see the difficulties around having auto-protection turned on by default for certain types. Depending on who is using it and their settings etc. Having lots of trash data build up is a bad thing for sure. What about this as a solution, riffing on what has been outlined above:

• Add a confirmation window (which can be turned off in preferences / in the window itself) that warns of orphaned non-protected data being deleted at close. Similar to what @BC (ChinoD) has mocked up. There could be three buttons, one to go to the data-block viewer to see the data that has no users, and no protection, where the user could protect those items they wanted to protect. The second button would cancel the close. And the third would "Delete Data" and close blender. This way it could prevent accidental data loss due to orphaned data not being protected.
• Add a data-block viewer or better yet a mode to the asset browser, that allows for a complete view of the current blender file. All of the data-blocks would be viewed / relevant blocks would have previews (e.g. textures, materials, objects). It could have filtering and sorting based on type / properties etc. and have search. This would also be the place where items like materials could be created without having to associated them with an object, and be applied to a whole selection, instead of just a single object, renamed, deleted etc. The asset browser would have three modes, one to see all assets marked as such, one for assets inside this file that are marked and shared outside this file, and one for all data blocks inside the current file. From here you could see what the data-blocks were linked to etc.
• Allow for materials to be edited without being associated to the current selection.
• Rename Fake User to Protect or something like that. Fake User as someone new to Blender doesn't make any sense. Renaming Users to Links would also help clarify what it actually is. The object centric paradigm of Blender seems to make Materials and Textures etc. worthless if they're not associated with their betters, the Objects ;)

Also what do you people think about how the delete menu option in the outliner works? It doesn't send those items to orphaned data, it straight removes them (when doing so from the orphaned data view). Is that true deletion occurring?

Personally, I like everything you've suggested here. To answer your question regarding the delete menu option in the outliner orphan data view, I think it's a true deletion. That being said, my understanding of blender's data management could be incorrect. I think deleting an item this way is like doing a single item purge. In fact, it's more potent and will even delete items with Fake User activated.

The proposal looks interesting.
It is a complex system design question, so it is hard to predict if different measures will be efficient, define which one will actually be, or all the possible consequences that could make situation even worse, so it is definitely better to not to solve such a problems in a rush.
Proper solution may take several iterations.

There is quite ancient industry level project management problem.
Due to lack of overall care, you have to basically live in garbage, and also lose or doom someones data at some point when the amount of garbage becomes huge.
Such data management debt quickly turns critical on a massive production.

In Blender, this problem has been solved by distributing the data management load between editing sessions.
As a result, a garbage-free system was obtained.

As soon as you have a system designed to be garbage-free, it has a very interesting property - it is able to manage any kind of garbage, including making it physical.
As a result, it is possible to pack external data into files without consequences.
This way Blender can afford packing into files external data and even Autopack external data feature, which is compensated by Autopurge data management system solution, making blend files flexible and always complete.

There are many different data management systems on the market, but none of them are ideal.
There are various software solutions that allow you to package data into files, such as Photoshop or Substance painter, but the problem is that these programs were designed for local personal workflows, such as asset creation, and were never intended to process large-scale projects in them.
As far as we know, Blender is the only program that has successfully scaled up the packing/Autopaking feature to mass production because of a system design solutions that allow this.

@Paul Kotelevets (1D_Inc)

I'm definitely on board for helping keep team projects efficient and garbage free. It seems like the options are quite binary at the moment where you either have garbage building up if people are not organized, or people loosing data if they're not careful to mark those items as something they want to stick around.

A couple questions:

1. What constitutes garbage? Is that anything that isn't being currently used in the scene?
2. Would you be up to having the fake user system revamped to be renamed something more appropriate like "Mark Persistent" and having users be instead "Links"? So in this way items that didn't have any links could be marked as a persistent asset while also having zero links. It doesn't make sense to have items that have zero links and are on the chopping block marked with a fake link, when they still have no links. Instead mark them as protected / persistent items
3. What other alternatives are there to this binary situation where you're either trusting the human to keep things organized and clean, or where you're not trusting them and throwing out potentially important data?
4. If the issue is external data being packed into the file, couldn't those items be the ones that should be automatically referenced instead of packed into the file?

To clarify, my problem with the current setup is that blender treats materials, for instance, as second class citizens to objects, and that those objects also need to be used in the scene otherwise they're thrown out. Basically things like materials have no right to exist on their own. They're always subservient to objects.

What are your thoughts?

In T61209#1308778, @Mike Drake (LichenDigital) wrote:

@Paul Kotelevets (1D_Inc)

I'm definitely on board for helping keep team projects efficient and garbage free. It seems like the options are quite binary at the moment where you either have garbage building up if people are not organized, or people loosing data if they're not careful to mark those items as something they want to stick around.

A couple questions:

2. Would you be up to having the fake user system revamped to be renamed something more appropriate like "Mark Persistent" and having users be instead "Links"? So in this way items that didn't have any links could be marked as a persistent asset while also having zero links. It doesn't make sense to have items that have zero links and are on the chopping block marked with a fake link, when they still have no links. Instead mark them as protected / persistent items

Renaming is more a matter of terminology than system design, since renamed things remains the same. I am not much fluent in English anyway. And it is probably better to discuss a system first.

4. If the issue is external data being packed into the file, couldn't those items be the ones that should be automatically referenced instead of packed into the file?

This sounds similar to cancelling external data packing - systems with no packing external data ability behave like that. Losing autopacking ability will be quite a damage and also breaking backwards files compatibility.

1. What constitutes garbage? Is that anything that isn't being currently used in the scene?

Yes.
I think it is impotant to observe a reasons behind this solution.

Users come to the sofware for creating content, which is quite logical - we are not familiar we any artist who came to software for things like data management instead.
The market is also built around the representative part, such as portfolios and artistic skills (pictures, models, animations - the representing product).
To make portfolios and skills learning software users usually perform as individuals.
As soon as they step into any kind of collaboration in any kind of software their data management is not personal any more, and they are forced to follow almost the same rules to avoid conflicts.
This is usually achieved through a fairly rigid corporate management mechanisms.
The point is that in any software those rules are just the same - "all the unused data will be lost during the very first massive purgeout", the only difference is that Blender users follow it from the very beginning and are prepared to avoid that.

As a result a question of a data management way is a question of an individuals vs collaboration, the point is that Blenders data management infrastructure was originally built on the service of collaboration.
It is probably not a problem to make a choice, but before making it is important to realize that such a choice exists.

3. What other alternatives are there to this binary situation where you're either trusting the human to keep things organized and clean, or where you're not trusting them and throwing out potentially important data?

To clarify, my problem with the current setup is that blender treats materials, for instance, as second class citizens to objects, and that those objects also need to be used in the scene otherwise they're thrown out.
Basically things like materials have no right to exist on their own. They're always subservient to objects.

Those questions drills our brains for a years. Otherwise, we would have already proposed a solution.
It is generally unknown how to make a system designed for collaboration comfortable for individuals, or how to make a system designed for individuals comfortable for collaboration.
We are not familiar with any massive production system out of this binary in practice (I even can't remember any other software with Autopack feature), and would like to know if some software took such kind of a risk.
At the moment we know that we can trust data management any Blender user, even not very experienced one.

I want to share our system integration experience.
There are 4 data management complexity levels, sorted by software use and type of data input, datamanagement demands depends only from the level you belong to:

• Individual use + vanilla data
• Individual use + imported data
• Collaboration + vanilla data
• Collaboration + imported data

As an architectural company we belong to the fourth level, so we have to deal with different software integration, having some "common denominator" - a software final projects are combined in.

Since Maya is officially promoted as a software designed around collaboration ("a place where modellers meet developers meet vfx artists" and so one), we originally decided to use Maya+Arnold for such kind of purposes, and use
Blender with 3dsmax+Corona at the local level.
The resulting system looked similar to this.

Maya and 3dsmax has pretty much the same well known data management systems and structure (slate material editor, no external data packing/purging, global node editor and so one).
The problem we faced is that due to huge amount of a various data sources that generates lots of data and the amount of changes during design process in teamwork, our Maya division most of time was trying to handle and sort a lot of garbage data which inevitably fell into a common denominator from all those data sources.

At some point we decided to make a restructuring and get rid of using Maya completely (to avoid a number of reasons and limitations, including these), using Blender+Cycles as a common denominator instead, since its data management approach had no such kind of a problems at all.
Our assumption worked pretty well and the resulting system looks something like this.

Of course, our example is far from universal, but I think it's important to mention the conditions in which we use Blender's garbage-free data management system and the reasons we prefer it in practice.