How should Saros handle the deletion of non-shared files?

6 views
Skip to first unread message

Tobias Bouschen

unread,
Sep 23, 2018, 8:36:41 PM9/23/18
to saros...@googlegroups.com
Hi all,

while working on participants being able to create/delete/move files
during a sessions, I stumbled about a corner case: How should we handle
deletions of non-shared resources on the receiving side.

As an easy example:
Alice and Bob start a partial session on the following directory structure:
Directory A contains the directories B and C.

directory A
|-> directory B
|-> directory C

In the session, only the directories A and C are shared, B is *not* shared.

What should now happen on Bob's side if Alice deletes(/moves/renames)
the directory A? This issue gets exacerbated by the fact that non-shared
directories don't have to exist for every client, meaning Alice might
not even know that she would also be deleting other directories for Bob.

Franz's suggestion was to look at how Saros/E handles the situation.
While testing the behavior, I noticed that deleting/moving/renaming
shared files in a partial session are not possible in Saros/E (see
GitHub issue 235: https://github.com/saros-project/saros/issues/235).

So now I am looking for a sensible behavior to handle such cases.

I can currently think of four possible approaches:

1. Handle these directories as though they were shared.

2. Just mark the deleted(/moved/renamed) shared directories as not
shared instead of really deleting them, thereby removing them from the
session while still maintaining the correct path for the initial
non-shared resources.
This approach still leaves the issue of how to handle subsequent
re-creations of the deleted(/moved/renamed) directories. Or in other
words, how do we handle the creation of resources that already exist as
non-shared resources for other participants?

3. Move the non-shared resources up the directory tree until they are
located in a valid directory.

4. Ask the user how to handle the non-shared resources. Offer options
like "Move the resource to a new directory", "Delete the resource", etc.
This approach might be the most user friendly but is might also be very
cumbersome if many non-shared resources are affected (as we should
probably create a dialog for each affected base directory).

I would appreciate your input on the situation and my suggested
approaches or other suggestions on how to handle such situations.

Best regards,
Tobias

Stefan Rossbach

unread,
Sep 24, 2018, 5:57:25 AM9/24/18
to Tobias Bouschen, saros...@googlegroups.com
Hi Tobias,

such a configuration cannot happen,

please see:
https://github.com/saros-project/saros/blob/master/de.fu_berlin.inf.dpp.core/src/de/fu_berlin/inf/dpp/session/internal/SarosSession.java#L242

You can even read
https://www.inf.fu-berlin.de/inst/ag-se/theses/Held11-saros-partial-sharing.pdf
but I do not think this will help you. I have not found anything useful
in this document regarding what partial sharing can handle / should
handle and what not.

Tobias Bouschen

unread,
Sep 24, 2018, 9:32:50 AM9/24/18
to saros...@googlegroups.com
Hi Stefan,

Hmmm, that's weird. From my tests, such a configuration is currently
possible with Saros/E. You can share a project using the menu entry
"Saros" > "Share Project(s)...". There you can individually choose which
files/directories to share. If you un-select a resource such as the
directory B, the activities on the contained files will not be shared. I
re-tested it just now with the current master branch.

I got to this topic as such a situation is possible in Saros/I
independent of whether we have a partial session or not. Currently,
Saros/I can only share a single module. Furthermore, it does *not* share
the sub-modules of the shared module. This leads to the mentioned
situation as other participants could theoretically have any number of
sub-modules located somewhere in the shared module.

While testing partial sharing in Saros/E, I also noticed another weird
behavior with partial sharing: Partial sessions no longer remove files
only present on the client's side during the negotiation. These
superfluous files can still trigger a desynchronization alert, but it
can not be fixed through the recovery. Furthermore, the host throws an
error at the beginning of the session for each of those files:
ERROR 01:54:52,833 [main] (BaseResourceSelectionComposite.java:318) Did
not find resource with uri in workspace root to apply selection:
/alp/src/de/fu_berlin/alp4/Main.java
How is a partial session supposed to handle files only present on the
client's side that were not explicitly set as not shared? Should these
files be removed by the negotiation? If so, I will create a new ticket
for this issue (or you can do it if you feel like it ).

Best regards,
Tobias

Stefan Rossbach

unread,
Sep 24, 2018, 9:54:51 AM9/24/18
to Tobias Bouschen, saros...@googlegroups.com
IIRC this was once the case. But as nobody paid attention to this (we
know nobody reads the dialog that will display the changed / deleted)
files, I think I changed it. There is also a check in the
AbstractIncomingProjectNegotiation that will prevent file deletions
during partial sharing.
Reply all
Reply to author
Forward
0 new messages