[TD4 Android] Local changes silently overwritten

Use this forum to report bugs you find - Benutzen Sie dieses Forum, um Fehler zu melden, die Sie finden

[TD4 Android] Local changes silently overwritten

Postby FHG » 02 Jun 2016, 23:08

Hello there,

I am experiencing a serious problem with TeamDrive overwriting local changes without any notification. Something like this has been reported in "TeamDrive setzt Dateien zurück auf alten Inhalt" (http://forum.teamdrive.net/viewtopic.php?f=4&t=968), but in a different system environment and in "Speicher offline->TD ersetzt Dateien durch ältere Versionen?"(http://forum.teamdrive.net/viewtopic.php?f=4&t=2843), but only in relation to losing server connections.

I am using TeamDrive 4 Version 4.1.6 (Build 1443) on Android 5.1.1 and on Android 4.2.2, both showing the same behaviour.

How to repeat:
  1. Prerequisites:
    • A file in a space on the mobile device (let's call it tdtest.odt, typically located in a path like /storage/emulated/0/Android/data/com.teamdrive.client/cache) with
    • content "Status 1"
    • synchronized with the server
    • configured to be available offline
  2. Open file on mobile device through file manager in Android OpenOffice (AOO)
  3. Change content to "Status 2".
  4. Quit AOO.
  5. Open file through file manager again in AOO.
  6. Verify that content is still "Status 2".
  7. Quit AOO.
  8. Check on other client that no new version has been uploaded to the space.
  9. Open file on mobile device though the TeamDrive client in AOO.
  10. Verify that content is back at "Status 1".
  11. Quit AOO.
  12. Open file on mobile device though a file manager again.
  13. Verify that content is still at "Status 2".

Without any warning whatsoever, the TeamDrive Client has wiped the local change. Only when I open the file through the TeamDrive client, return from the editing application to the client, will the client ask me wether I actually want to keep the changes.

I have used the file manager here for clarity, but applications that keep their data in a standard file fall into this trap regularly.

Especially after switching from DropBox, which has no problems with this scenario, this is a very unpleasant suprise. I am thoroughly amazed that this quite normal use case is handled this way.
FHG
 
Posts: 1
Joined: 01 Jun 2016, 20:38

Return to Bug Reports - Fehler Melden

Who is online

Users browsing this forum: No registered users and 11 guests