Trashing a collection now deletes the content too
We've recently changed what happens when you trash a collection. When you send a collection to the trash, you will now see a message warning you that it will also be sending all of the content in that collection to the trash as well. When you purge the trash, then all of the items in that collection will also be purged.
At the moment, items that are in more than one collection, will not be deleted. This is temporary though, and in a few weeks, all items in a collection will be purged along with the collection. I'll update this thread when that is in place.
Let me know if you have any questions.
In a collaboration where several people create and share files and collections and add and remove edit permissions the sharing settings that I created for Alice and Bob would be nothing unusual. It will be an unpleasant surprise for all concerned to find that Alice is deleting Bob's files when they are not shared with her and she could not even see those files in her listing.
<<In Bob's view L0 is gone and also his private collection M0 and file doc0 have disappeared.>> Is that actually true? I would have expected Alice's "deleting" of items she does not own simply to remove them from her view, just as "deleting" a single file one does not own doesn't in fact delete the file for anyone else (only an owner can really delete it).
@Gill, yes, it was true then and it is still true today. In order to replicate the error one must follow the steps carefully. Bob must create M0 and doc0 while his view is in collection L0; it does not suffice for Bob to create M0 and doc0 in his home view and then move them into L0. I am reminded of the error found by daniel1960 in an early reply in , where it also made an unexpected and unwarranted difference whether a file was created inside a collection or whether it was created in home and then moved into the collection. That error too could cause files to be wrongly deleted . These Alice and Bob situations that I create here and in some other experiments [3-7] are nothing fancy and the objectionable conditions are brought about while using only sequential operations on the file structure. (The conditions in [3-7] are rather harmless compared to the one discussed here or the one in [1-2].)
The present example has a further variant in which Bob removes L0 from his Docs list after creating M0 and doc0. The situation is then that Alice is not on the share of M0 and doc0 and doesn’t see those items while owner Bob sees M0 and doc0 in his home view and not in any shared collection. After some time both Alice and Bob may forget about the history. When Alice deletes L0 she will not know what she has wrought and Bob will never know what has hit him. All he knows is that somehow Google lost his docs. In its own perverse way it is a beautiful error: easily described, totally reproducible, devastating in its consequences and almost untraceable. It also reflects a multitude of sub-errors in the way in which history makes an incorrect difference. On the one hand there is the difference (as for daniel1960 in ) between creating an item in a collection or creating in it home and then moving it into the collection. On the other hand the history of the share is important; if we have Bob creating L0 and transfering ownership to Alice then the example doesn’t work.
Good programming makes use of a precise specification of the allowed states of the system and the programmer takes care that all operations transform an allowed state of the system into again an allowed state. The precise specification for the programmers goes together with good user documentation and with appropriate interface design, both of which are lacking for the Gdocs file system. (For the documentation see my explorations of the file structure in  and for the interface see my comments about the inappropriate design of the left panel in .) I’ll say that when the coding errors, poor documentation and poor interface design are taken together maybe it points to some structural problems.
Some community members might have badges that indicate their identity or level of participation in a community.
Member levels indicate a user's level of participation in a forum. The greater the participation, the higher the level. Everyone starts at level 1 and can rise to level 10. These activities can increase your level in a forum:
- Post an answer.
- Having your answer selected as the best answer.
- Having your post rated as helpful.
- Vote up a post.
- Correctly mark a topic or post as abuse.
Having a post marked and removed as abuse will slow a user's advance in levels.
View profile in forum?
To view this member's profile, you need to leave the current Help page.
Report abuse in forum?
This comment originated in the Google Product Forum. To report abuse, you need to leave the current Help page.
Reply in forum?
This comment originated in the Google Product Forum. To reply, you need to leave the current Help page.