/docs/community?hl=en
/docs/community?hl=en
8/30/11
Original Poster
Bas Braams

Remove a file from a collection and the file disappears completely

In an earlier posting [1] I showed some strange behavior with shared files. The strange behaviors in that posting had to do with a hidden containment relation. Other surprising history-dependent effects were discussed under [2]. The discussion is of practical interest; such hidden variables also caused the situation that for a period of 2.5 months under clearly defined circumstances it was possible for a person to delete files that he did not own and could not see [3].

Here is a related and yet different situation where file operations depend upon the history of the file setup in a surprising way. Again, some kind of hidden variable is at work. The present hidden variable manifests itself when someone removes a file from collection and the file (doc0 here below) is then completely lost, also not found under Home or under All.

Alice creates collection L0 and shares it to Bob with edit permission. She then creates side-by-side doc0 and doc1 inside L0; these documents are thereby also shared to Bob with edit permission. Now Alice first removes the edit permission for Bob on doc1 (leaving view permission only) and then restores the edit permission for Bob on doc1.

Bob sees L0 and it contains doc0 and doc1. Bob has edit permission on L0. Using the Organize menu he removes doc0 and doc1 from L0. He probably expects to find both under Home still, and if not under Home then under All. However, the effect of the operation is that doc0 is lost for Bob and doc1 is found under Home.

When Alice inspects the situation she finds L0 empty. (This is understood.) She finds doc0 and doc1 in her Home. She also sees that doc0 is no longer shared with Bob and doc1 is still shared with Bob.

It all hangs together, but not, I think, in a way that reflects correct design. If the action by Alice of first removing and then restoring edit permission for Bob on doc1 affects future operations then there should be some visible variable associated with that. Hidden variables basically reflect design errors, I think.

[1] Hidden file structures and surprising side-effects

[2] Moving a collection to trash does not trash the documents inside

[3] Possibility to delete files that one does not own

Community content may not be verified or up-to-date. Learn more.
All Replies (2)
8/31/11
Original Poster
Bas Braams
Let me add a comment about the hidden variable. An item has a sharing status, and we know a few possibilities: it can be not shared, privately shared, shared to anyone with the link, or shared public on the web. Apparently there is another possibility: the sharing status has the value "dynamic". (We knew this, actually, but it is useful to bring it into focus.) When an item's sharing status is "dynamic" then the apparent sharing status depends on the sharing status of the parent collection or parent collections.

Fine, we can work with that. But then it has to be documented, and not just the existence of this value but also the rules for how the value is obtained or changed and for how it manifests itself. (Keep in mind that an item may be in more than one collection.) Suppose we give an item an explicit sharing status, as Alice did with doc1 in the earlier example. Are there any operations that will change the status of doc1 back to dynamic again?
9/3/11
Original Poster
Bas Braams
Here are some explorations of operations that affect the dynamic property of the sharing status.

Alice creates collection L0 and shares it view only with Bob. (It is easiest to start this way, not sharing with edit permission, because it limits what Bob can do with L0.) Within L0 Alice creates documents doc0, doc1, doc2 and doc3. They are all automatically shared with Bob view only.

Bob opens L0 and visits doc0-doc3. (I don't know if this step is important, but it confirms that the share is effective.) Indeed, the collection and the files are shared with him view only.

Bob does nothing further with doc0. He removes doc1 from his home view. He assigns doc2 to his own collection M0. He removes doc3 from his home view and also assigns it to his collection M0. All these actions of Bob are invisible to Alice; she does not know how Bob arranges his Home view and she does not know about Bob's collection M0.

Alice now removes Bob from the share on L0. If she is accustomed to dealing with passive recipients of her shares then she may expect that Bob is thereby also removed from the shares on doc[0-3]. However, Bob being the active kind, it doesn't work out that way. We do the experiment and find that doc2 and doc3 are still shared with Bob and he can find them in his M0 collection.

I think that all this behavior is undocumented and I suspect that it hasn't been thought out either; it is just the way that things may be discovered to behave given how the GDocs file system code happened to be written. I think that it is wrong behavior too. Alice is the owner of L0 and of doc[0-3] and the sharing status of these files should depend on her actions alone and not on Bob's action (invisible to Alice) of assigning some such file to one of his private collections.

There is a further anomaly. After Alice removes Bob from the share on L0, Bob finds doc2 and doc3 under his M0 still, but he doesn't find them in Home or in All items. He also doesn't find them by searching for * under All items. However, after he opens them again from inside M0 then they are visible under All (and doc2 also under Home).
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.