I was now able to reinstall Anytype by renaming Anytype’s Library folder, in addition to deleting the app from the /Applications folder.
So my vault reloading now => no urgency for this issue anymore.
Thank you for your swift response!
A big thanks to the Anytype team for the 0.55 update! Apart from the issue I had raised earlier, I’ve been super grateful for the update: lots of very welcome bug fixes!
Thank you for addressing this. This is a critical issue because it directly affects data integrity.
1. The main issue is that the “Origin” property is assigned automatically and is permanently hardcoded to the object. It doesn’t change even if I duplicate the object or change its type. As a user, I shouldn’t have to remember how an image was added—whether it was via Drag’n’Drop, pasted into a document, or via the Upload menu. This metadata shouldn’t dictate the object’s life cycle.
2. I’ve noticed that some automatically deleted images appear in the Bin nested within a Collection, while others appear separately. This inconsistency makes data recovery confusing and unreliable.
3. If I drag an image into a Collection, the “Unlink” button effectively acts as “Delete.” This is an unacceptable overlap of functions that leads to accidental data loss.
Answers to your scenarios:
- Scenario 1: Leave images in the library.
- Scenario 2: Leave images in the library.
- Scenario 3 : Leave objects in the library.
- Scenario 4: A confirmation dialog is mandatory for every action that affects more than one object at a time.
Under no circumstances should the “hidden logic” of the app deprive me of objects I’ve collected. I am more than happy to manage an “orphaned view” manually if it means my data stays safe. I categorically refuse to play detective and hunt for missing objects just because the app decided to be “too smart” for its own good. Data safety must always come before automated “cleanup.”
You should use the last version that has worked for you, of course.
Very clear for ALL cases:
Always with a confirmation dialogue that asks the user!
Pre-selected should be “Remain child Objects”.
Even if there are images in a Page that are no separate Objects, I would very clearly prefer that these image become individual image-Objects if the Page becomes deleted. (Except if the user decides otherwise in the confirmation dialogue).
For Objects in a Collection it is even much more clear the the Objects should remain! Again: except the user actively decides otherwise in the confirmation dialogue.
True!
Furthermore, restoring individual files from the Bin becomes even more convoluted when they are tied to a Collection. You can only restore a Collection with all its contained images at once. What if I only need some of them, but not all? If I restore a single image and then later restore the Collection, the image gets sucked back into it. In your own documentation, you emphasize that Collections are manual—and only manual—sets of data. The mere existence of a link should not create extra work. It should be simple: create a link, remove a link. That’s it.
The app’s logic regarding creation methods and context is fundamentally flawed. It fails to give users a clear understanding of which creation methods are “safe” and which are dangerous for their data integrity. There are almost no convenient ways to add multiple images at once, and without a dedicated Inbox, users are forced to create temporary documents and collections for mass imports just to get by. The core usage scenario of any PKM implies sorting and organizing content over a long period of time, not being punished for how the data was initially brought in.
My expectation for a local-first solution is that it shouldn’t just be a ‘safe’ — it must be a nuclear-grade bunker.
The entire premise of Anytype is built on user sovereignty and data ownership. When I store my knowledge locally, I expect a level of reliability where not a single byte disappears without my explicit, conscious command. A ‘smart’ application that decides what is trash and what is not based on hidden metadata like ‘Origin’ or ‘Context’ is a сatastrophic violation of our trust.
Dear @UBr , make sure that you manually copy things like the Custom Dictionary (for spell checks); as well as your custon.css and maybe other relevant files.
I’ve lost my well made Custom Dictionary three or four times because of cases like yours …
Being able to delete a collection and all its contents is great news; I’ve struggled too often with cleaning up spaces (as I’ve mentioned elsewhere, now whenever I can, I delete the space and then recreate it—it’s simpler). So thank you. Now we just need to fine-tune it 
In my case only :
- If images only here, cascade to bin (by the way, I like the principle you mentioned: distinguishing between whether the item was added to the page/collection or linked to it later—a concept that aligns with how I use it)
- Same
- I’d be tempted to say the same thing, but I think there are more exceptions here. I use collections for organization, so the content doesn’t always have to disappear when I organize.
- Same as other : always (or configurable).
My ideal solution:
- Keep the global delete option on the collection or object for items with no other links
- Display a simple confirmation prompt: users should be able to quickly click “Yes” or ‘No’
- A “Review Before” option could be a useful addition: it would display a list of the objects to be deleted and a new confirmation prompt. But in my opinion, this isn’t essential, and we should avoid having it in the confirmation pop-up, which needs to stay simple, clear, and fast!
- And I’d add one thing that tends to be overlooked in Anytype: offer an effective rollback!
I’ve mentioned this before: the rollback (CTRL+Z) is the safety net that gives you peace of mind when it works well. You feel confident, knowing that no matter what you do, one or more CTRL+Zs will take you back!
In Anytype, this safety net is full of holes (well, more than just a net…), so there’s no confidence, and we hesitate to dive in or even test things out.
Here, a CTRL+Z should be able to restore the collection to its previous state, including any discarded items if applicable.
Seriously, please improve this aspect and keep it in mind—systematically and everywhere!
Ctrl + a does the trick to select all items in a view. Then you can delete them all together.
To clean up a space from all Objects, simply use a Query that lists all Objects.
Because that was always possible, I wonder why the team suddenly come up with the concept to delete Objects together with the parent Collection?
The way it always was comes with an inherit second level of security.
I’m not strictly against the new concept, as long as it comes with a confirmation dialogue that gives the user the choice. If that’s given then it’s OK for me.
But if the bulk deletion happens automatically, without such a user choice, then I foresee a user revolution (with me in the first line of the front)!
Months later, it will be impossible to remember exactly how each object was added to a collection. No amount of speed or convenience can ever justify the risk of data loss based on such obscure criteria. In an app built on object relations, it is impossible to account for every bug or undocumented ‘quirk’ with every new update. Therefore, cascade operations should be eliminated as a concept.
Given how this ‘feature’ was hidden from us, catastrophic data loss is only a matter of time!!!
The higher the level of deletion—whether it’s a block, an object, a collection, or a space—the more deliberate and rigorous the confirmation must be. For instance, I have already lost an entire space on my phone due to something as trivial as wet fingers. We need friction where it matters most: protecting our data.
I completely disagree 
.
And we need to distinguish between the “source” mechanism (which, yes, I personally like because it works well for my needs, but which isn’t right for everyone, as I mentioned in my post) and the cascade deletion mechanism, which would save lives! Well, at least some space (the topic of orphaned objects on the forum is quite enlightening 
), even if there are always tricks for cleaning things up. But personally, not having to do too much cleaning up—I think that’s even better.
So I want and I’m voting for cascade deletion, with the safeguards mentioned.
Oh, that reminds me! (copy @kaye, maybe something to look into for Collections 2.0)
One of the annoying things when cleaning up a space is that you also have to delete properties (e.g., I create a “Books” collection 2.0 in a space with all needed properties but then decide I don’t want it anymore—I have to delete the collections, the items, AND the properties; Or take the case of Experience Gallery items, which can permanently ruin a space—I’ve been there 
).
Does not make sense to me. The files have to be tiny, so it cannot “save lives”. If the files are huge, they are easily sorted by size and easy to clean. A user can actually “save lives” with buying a bigger space subscription from Anytype.
What must never exist is a non deterministic “delete function”. It either deletes or it does not. I do not want a “maybe it will delete”. There are some things that convenience takes a step back to determinism. Specially when having a 10+ items collection, it is not direct to see which objects have backlinks or not. Current also, some “backlinks” are not even created when they should be (links in discussions).
It should be an option, “never delete”, “delete non-linked/ask user question” with a list of objects about to be deleted. There is a reason file managers do this. Deletion is deterministic, there is no “maybe it will, maybe it wont”.
Exactly… doing so right after creating a collection is easy, but the issue is months or years later.
An easy solution is to have 2 buttons: “Delete” and “Delete and Clean”. That seems the best of both worlds: Use clean when and only when one wants, and no “magic code should we or should we not”.
@n7cgu4sxyjzl @Code-Jack @Shampra @sturdily thanks for all of your thoughts. Regardless of the different positions, it’s clear that the current implementation is insufficient. Additionally, the status quo of a noisy space with many orphaned/useless objects is also an issue. So we need to iterate further on a better solution.Personally, @requilence’s #1 scenario makes a lot of sense to me—where I 100% want cascading deletion.
As an example that happens every day: there are times where I’m writing a document, I put images inside the blocks, turns out its the wrong image, I delete the image block and replace it with a new image, etc. When I finally finish the document, I may have uploaded 10 images in the process with only 4 remaining in the final document—what should happen to those 6 ‘useless’ images? Historically, I had to go hunt down these ‘useless images’ to delete manually because the system had contextual deletion.
- Today, images added to an object via drag n drop into a block are treated differently to those added via the /file block command.
- If you drag 'n drop an image into a page and then delete the image, it will automatically move to the bin. The system will display a toast signalling this.
- If you add an image into a page with the /file command (meaning you needed to have uploaded it the space prior) and then delete the image block, it will only remove the image block but keep the image as an object in the space.
This makes sense to me because images created via drag n’ drop into a page is very likely to be intrinsically connected to that object and hold very little relevance to the rest of the space without that object. Thus, if I delete that object, it makes sense that those drag n’ drop images cascade delete with it. This is different from an object that I had uploaded separately via the ‘upload from computer’ feature, which I then added to a page via the /file command afterwards.
I agree that this ‘smart system’ is making assumptions that may not always be true. Additionally, I agree that users will not remember the context for these objects/images creation in the future when they delete things. Having no ‘smart features’ means that it puts a lot of onus on the user and asks for a lot of confirmations—which is not so intuitive. Having ‘smart features’ means it works well to the user invisibly, but at times when the assumptions are wrong, it creates a strong dissonance.
--
I question if a simple delete feature is better with no ‘smart’ cascading deletion whatsoever. However if there is a separate and very robust ‘clean space’ feature that looks for ‘useless’ objects, properties, types, collections, etc. and makes suggestions for deletion, maybe that’s a better approach.
@kaye I completely understand that users want a clean space. I understand why @Shampra and others want it. If it was for another action, I would not be so clearly opposed to it. But deletion is a destructive action. (yes, it goes to bin, but then one has to micromanage the bin, or else, in a 1000 objects bin, it is easy to delete wanted things/notes/images).
The issue comes with time. After one year, how do you expect me to remember:
- I uploaded this through /file
- I did not delete any links to the image. (Imagine that the image had 1 or 2 backlinks, but with time, they got deleted. Not that I did not want the image, but maybe I did not need the note/task to the image)
This is the way (IMHO). It is similar to how other systems work (e.g. Nixos, some Programming Languages). A garbage collector. The big win here, is like you said, more robust:
- Smart deletion in collections, only cleans collections
- Garbage collection, cleans whole space, probably with better algorithm, better cleaning.
By your answer, I can see I do not need to say anything else, you know the issues and have great solutions for it.
As offtopic… I also would say that I highly do not like the new space creation, appearing the members as first step. 2 main issues for me:
1.
- As someone that does a lot of testing, I have to go to the Top left to click on the “+” (new space)
- Then go to the bottom middle to skip adding members
- Then go into the middle of the screen to actually do what I wanted
- It is really not intuitive that I click on the “+” space and a question/selection of members appears. Specially for most users and most spaces, that will be single user.
@kaye , our appreciated sturdily brings a very well argument here.
Although automatisms seen to spare time, it would in this case move the time consumption the the micromanagement of the bin.
It forces the user to look twice more on each single item in the bin and sometimes even opening them to be sure. – It’s not always clear how they did get into the bin and why. It’s a guesswork.
And even if one could in principle restore items from there, you would go crazy if it has happen for 100 or 200 Objects among maybe 300 other Objects in the bin.
I mean, if someone really wants to delete the Objects inside a Collection, he can simply press Ctrl + a, follewed by delete.
– What’s the problem?
There was never a problem. – No need for dangerous automatisms.
.
And one important point more:
I have already missing Objects!
And I’m not the only one who has to deal with missing and/or corrupted Objets.
If there is in future one big point for failures and disasters more, then good night if users suddenly complain about masses of missing Objects where no one knows the reason!
Ah, thank you, dear @Code-Jack! I’ve preserved my custom.css and my keyboard shortcut mapping. Where is the dictionary located, and how does it get populated?
@sturdily @Code-Jack I wonder how do you feel about this current feature described, which isn’t necessarily cascading deletion—but a form of smart deletion. It simply moves to the bin any drag n’ drop images that get deleted from an object (that is also not used anywhere) else. My described user journey is likely a very common experience—users uploading the wrong thing into an object via drag n drop and then wanting to delete/change it. Do you believe that all of these should not be automatically moved to the bin and also kept in the space? For me, this simulates a much more expected behaviour in my experience.
If I upload an image in a document and delete it, I don’t expect it to stay in the space.
Hmm…
Cons : I have a space with lots of photos—not necessarily related to each other except for the fact that they’re all images—that I want to keep, of course. This is an example where, in my case, using the upload method would be useful, since obviously these weren’t uploaded to an object but directly to the space (well, actually to a collection, since back then we couldn’t upload directly).. This feature must manage this type of scenario (at the very least, let us be able to “confirm” which files to keep: if I still have my thousands of photos, the items that actually need to be deleted will get lost in the mix.)
Pros : Yes, a way to easily get rid of all those unused property!
Or not, as already discuss here : Line selector into Collection 2.0 - #6 by Shampra
But ultimately, the option to delete the collection—with the choice of whether or not to delete the content—addresses both of our needs and concerns 
: we can choose to delete just the collection if that’s what we want, or delete the content at the same time if that’s what we want. Now it’s just a matter of refining the UX to make it clear and seamless!
I think the new update messes up the app’s behavior with right-to-left languages. The app behaves “weird” about RTL, such as automatically aligning check-boxes to the left even if the line before was RTL.
Before the new update, it would automatically align the block based on the line before, and then automatically switch if the content was in the opposite writing direction. That made the working flow nice and easy because if I started writing RTL, the app would “predict” that this is the writing direction as long as I don’t start writing in a LTR language, and vice versa. Now, it always “assumes” writing direction is LTR, and even if I start typing in a RTL language, will only correct the checkbox alignment after I press enter to move to the next line. The cursor also always assumes LTR now. This makes the app almost unusable to me. I miss my workflow and I love this app, so please fix this bug.
I talked about the example of Nixos and PLs, that use GC.
I can give you another example, that works more like the example above: removing packages on Arch (or common FSB distros), remove just the package asked. There is an option to clean installed packages related to the package one wants to remove (similar to the use case you proposed). This behavior is not default, needs command line option, and still lists all the packages it is going to clean before deleting something.
Now to your use case, the use case is not the question. I use it all the time when removing packages on Arch. But I always review the list, not always the list is correct. It kinda reminds me the case of LTT (Linus Tech Tips), to install Steam deleted PopOS desktop!
Anyway, like I said above, I feel that whatever happens, I am not worried, Anytype knows the options and will for sure do the right thing…even if it does the wrong thing first.
You are getting into tricky territory, because to “save lives”, as @Shampra put it, you are laying land mines all over planet Anytype. that is the expected behavior if Anytype is hierarchical, not a network, not a graph ! So please, if you want to move to “this expected behavior”, make an announcement discarding the network graph, and moving into hierarchical folder/files.
That is only the expected behavior to some users, because those users are used to hierarchical folders/files.
Even in Obsidian, if I have a [](file:///), if I remove the note, it does not do a rm -rf /. If I create a note with a link to google, it does not delete google when I remove the note.
At the end of the day, is it network graph or a folder/file hierarchy ? or is it a mix match of both, depending on how I uploaded something last year, or 2 years ago?
Disclaimer: the example with images doesn’t actually make me care, as I do not care much about images (either it is not important, or is duplicated/triplicated elsewhere). But if I lose 2 or 3 tracks from my “Opeth - Ghost Reveries” album, because I was dumb and uploaded it incorrectly through drag and drop… to put it politely, “I will not love it”. If the same happens with a “vital” PDF, or another important document, it will be a show stopper.
I hope this explanation saves troubles for Anytype in the future. I myself will take extra care with deletions.