/docs/community?hl=en
/docs/community?hl=en
4/11/11
Original Poster
Rebecca

Trashing a collection now deletes the content too

Hi Everyone,

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.
Best wishes,
Rebecca
Community content may not be verified or up-to-date. Learn more.
All Replies (18)
Bas Braams
4/11/11
Bas Braams
I noticed it and the implementation is wanting [1]. Consider a collection C0 in which there are files ch, cp and cc. File ch is also shown in Home, file cp is private to C0, not occurring in any other collection, and file cc occurs in another user collection as well as in C0. We move C0 to the trash and empty the trash and then see what has happened; it turns out that C0 and files ch and cp are gone and file cc is preserved, consistent with what Rebecca described here above. (Note that occurring in Home does not protect a file against this deletion.) But now look at the intermediate stage, where collection C0 has been moved to trash and the trash has not yet been emptied. The view in Trash at the intermediate stage is really strange. We see collection C0 there, and inside collection C0 we see file cc. Files ch and cp are nowhere to be found. (They are not reachable from Trash and not reachable from All items.) When we moved collection C0 to the trash we were warned that items in C0 would also be moved to trash. When we look for such items in C0 when it is in the trash we see file cc. It is natural to assume that this file is going to be deleted when we empty the trash. The actual behavior is different; file cc will be preserved, and the files that will be deleted are files ch and cp.
I provide more detail and raise some related issues in [1]; it includes a nice reproducible demonstration of how looking for files * changes the state of the file listing for later searches not involving *.

Gill
4/20/11
Gill
<<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 think that would be a big mistake, deleting all items in a collection even if they are also in another collection! A recipe for disaster and people losing files. Please think again.
Google user
4/21/11
Google user
Hi everyone.......You are probably wandring how to trash an item that you dont want anymore. Well i am assuming that if you clicked on this link. Anyways the way you trash an item is you go to the far left side of your screen and you go down the colums that are there until you find trashed then you click on that and drag the item you want to be trashed in there:) Pretty simple after you find out how right:)
Another way is to highlight the item you want to be trashed and clisk on the actions on the far right side of where it is highlighted. Then go down to trash and it trashes it for you:) Once again easy after you know how to right:)
                                                                                                     Thanks and if you have amy problems just reply
Bas Braams
5/1/11
Bas Braams
In addition to the strange behavior noted in my first reply the new treatment of deleting a collection has created some other issues. It is now possible to delete files and collections that one does not own and for which one does not have edit permission. It is even possible to delete files and collections that one does not own and for which one isn't included on any share. Alice creates collection L0 and shares it to Bob with edit permission. Bob enters collection L0 and creates there, side by side, collection M0 and file doc0. Bob is the owner of these items, but automatically Alice obtains edit permission on these items. Bob now removes Alice from the share on M0 and doc0, so that in Alice's file listing the collection L0 appears to be empty. Alice now moves L0 to trash and empties the trash. In Bob's view L0 is gone and also his private collection M0 and file doc0 have disappeared.
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.
rpdoug
5/10/11
rpdoug
I am having a huge issue with google docs.  Yesterday morning I logged on to my account and noticed that every one of my documents had been deleted.  At no point did I even move a single item to the trash over the past few days.  They are not in any folder in my collections or in the trash.  Either someone stole my account information ( I have not recieved a notice of suspicious activity) and  deleted all of my files or Google somehow purged all of my documents.  Does anyone have any ideas? I can't tell you how many important work documnets that I have created on there.
Gill
5/10/11
Gill
@bas
<<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).
Bas Braams
5/12/11
Bas Braams

@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 [1], 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 [2]. 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 [1]) 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 [8] and for the interface see my comments about the inappropriate design of the left panel in [5].) I’ll say that when the coding errors, poor documentation and poor interface design are taken together maybe it points to some structural problems.


docsusermd
6/9/11
docsusermd
i cant seem to delete documents or folders. i delete them, move them to the trash, empty the trash, but then wh en i log back in they have all returned.  ive seen this as an issue in multiple places but it seems to still be a problem for me at least. i also dread the idea that google may accidentally delete/purge other things i dont want deleted(as mentioned above)
Bas Braams
6/18/11
Bas Braams
It is still the case that one can delete a file that one does not own and cannot see, as described here above on May 1 and May 12 CET. Maybe those compact Alice and Bob scenarios appeared a bit artificial, so let me try another one with a bit more narrative, with apologies to readers that don't care for too much narrative.
Bob has to produce a document according to some company style. Alice has done it before. She takes a copy of one of her own documents, strips it to its essentials leaving only the basic layout in place, and gives it to Bob. We'll call this document doc0, and Alice has transferred ownership to Bob and has removed herself from the document completely. Alice cannot see doc0, much less edit it; it does not appear in her listing. Bob finds doc0 in his home space. He might rename it, it doesn't matter for what follows, but let's imagine that he renames it mydoc, keeping it in Home and not in any collection. To Bob, mydoc is owned by him and it is not shared with anyone else, and it is the starting point for his work. Bob now proceeds to edit mydoc. We may imagine that he works on it for several weeks without backing it up; after all GDocs saves a revision history.
Now we go back to Alice. She may have produced doc0 inside some collection, which we'll call L0, and may now reorganize her file space. Remember that she does not see doc0 (or mydoc) anywhere, not in L0, not in Home and not under All items. She may delete the collection L0 without any concern. And when she does so and empties her trash (bin in the UK) then mydoc vanishes for Bob together with all its revision history. Bob will not have a clue what happened. His file mydoc is suddenly gone. It was his document, not shared with anyone else. He is not going to suspect that anything that Alice did may have anything to do with this; Alice gave him the document weeks ago and that was the end of her involvement. The disappearance of mydoc is a complete mystery to Bob, besides perhaps representing the loss of some significant amount of work. Meanwhile Alice has no idea that she may have caused any harm. She deleted a collection that was owned by herself and that may have been completely empty as far as she could see. It is not a good situation.
Gill
6/19/11
Gill
<< It is not a good situation.>> Indeed it is not. If Bob puts the file mydoc into one of his own collections does that protect it from Alice's ability to delete it?

If not, in this situation one should always make a copy of the "doc0" I guess.
7 MORE
Bas Braams
7/18/11
Bas Braams
<<It is not under control by the programmers, and there seems to be no documentation; it's behaviour can only be explored experimentally!>> Yes, it is a bit harsh to put it that way, but it makes a valid point. It was 2.5 months that a non-owner could delete files, it goes back to errors that were perfectly well described much earlier ("daniel1960" as cited before), and various invisible links can still cause strange behavior [1].

However, it may be useful to record also on this conversation, following [2], that as of about 2011-06-22 it is no longer possible to delete files that one does not own.

Were these replies helpful?
How can we improve them?
 
This question is locked and replying has been disabled. Still have questions? Ask the Help Community.

Badges

Some community members might have badges that indicate their identity or level of participation in a community.

 
Google Employee — Google product team members and community managers
 
Community Specialist — Google partners who help ensure the quality of community content
 
Platinum Product Expert — Community members with advanced product knowledge who help other Google users and Product Experts
 
Gold Product Expert — Community members with in-depth product knowledge who help other Google users by answering questions
 
Silver Product Expert — Community members with intermediate product knowledge who help other Google users by answering questions
 
Product Expert Alumni — Former Product Experts who are no longer members of the program
Community content may not be verified or up-to-date. Learn more.

Levels

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.