Issues using dropbox app

[mmattel]

Environment:
ownCloud 10.0.10 (stable) on Ubuntu 16.04, nginx, php 7.0, mysql
Client 2.5.0 on Windows10x64
Dropbox App 1.0.1 via Marketplace

Setup:
Mount a dropbox with existing files and folders and let that mount get synced via the client locally.

Issues:
1.) Lowercase I

• Having the sync relationship setup successfully, all content gets first time synced (downloaded) to the local machine. In comparison to the DropBox (DB) Browser view or the DB client view, all files and folders are lower case.

2.) Lowercase II

• Create a file (best outside of the sync relationship), eg test.txt and copy this file into the sync. The file gets synced. You can also do this sucessfully via the oC Browser. Interestingly the file gets uploaded quickly, no error or issue is shown on the client or server, but the file itself has a red warning that it is not synced. If you go to the oC browser and refresh the page, the file is shown, it seems a backsync happens and the file locally shows green and is in sync now.
• Rename the synced file so it contains upper and lower case characters test.txt --> Test.txt.
  No errors on the oC.log, Client: Error transferring <...>, Server replied: (empty), after a short time it changes to ...replied: skipping because of an earlier error, retry in...
  Test.txt has a red warning. Refreshing the oC Browser, I have now two files test.txt and Test.txt, but not on the client (naturally Windows specific upper/lower case stuff)

3.) Server does not support X-OC-MTime

• This issue is addressed in Activity message on file upload (dropbox target): Server does not support X-OC-MTime client#6797 and is linked here for completeness
• You get that eg, by deleting both Test.txt via the oC browser, the client shows Test.txt: Server does not support X-OC-MTime

4.) Delete the file

• Issue 2 created two files, which were visible via oC Browser, test.txt and Test.txt.
  After deleting successfully via the browser Test.txt, the file test.txt remained. That file is visible in the Browser but not on the client side. On the browser side, marking the file and deleting it did not succeed and the file remained (no error). A browser refresh does not trigger/change anything on the client side.
• Forcing the client to sync, forced the server to remove the file. After a browser refresh, the file is not longer visible.

Note:
You can do all of these test easily by yourself and maybe find additional strange behaviours.
Overall, this kind of setup has room for improvement as the current situation makes that combination barely usable.

@PVince81, @ogoffart FYI

[mmattel]

Update: case 3 got fixed with owncloud/client#6800, already merged.

Any updates on 1, 2 and 4?

@cdamken, @ckamm maybe fyi too...

[ckamm]

The lowercasing you're seeing is from #27 - which looks like it's been fixed in a PR, but there's no release containing it yet.

Currently the desktop client doesn't support working with servers that don't preserve file path casing as far as I'm aware. It's probably mostly ok on windows (because that isn't case sensitive either), but will fail badly (like this) on linux. (@michaelstingl)

[michaelstingl]

@pmaier1 FYI ^

[PVince81]

renaming a file with similar casing is also a general issue in core and Sabre, see owncloud/core#17161

[PVince81]

these issues should really be separate tickets. we'll recheck them before releasing the latest app state to see if they still exist and raise tickets accordingly

[davitol]

Test issues with oC 10.0.10 and tarball https://cloud.owncloud.com/index.php/s/KTwSnsPUmccpQpQ

Issues:

• 1.) Lowercase I (fixed)

  Having the sync relationship setup successfully, all content gets first time synced (downloaded) to the local machine. In comparison to the DropBox (DB) Browser view or the DB client view, all files and folders are lower case.

• 2.) Lowercase II (Same behavior with latest tarball)

  Create a file (best outside of the sync relationship), eg test.txt and copy this file into the sync. The file gets synced. You can also do this sucessfully via the oC Browser. Interestingly the file gets uploaded quickly, no error or issue is shown on the client or server, but the file itself has a red warning that it is not synced. If you go to the oC browser and refresh the page, the file is shown, it seems a backsync happens and the file locally shows green and is in sync now.
  Rename the synced file so it contains upper and lower case characters test.txt --> Test.txt.
  No errors on the oC.log, Client: Error transferring <...>, Server replied: (empty), after a short time it changes to ...replied: skipping because of an earlier error, retry in...
  Test.txt has a red warning. Refreshing the oC Browser, I have now two files test.txt and Test.txt, but not on the client (naturally Windows specific upper/lower case stuff)

• 3.) Server does not support X-OC-MTime (fixed)

  This issue is addressed in Activity message on file upload (dropbox target): Server does not support X-OC-MTime client#6797 and is linked here for completeness
  You get that eg, by deleting both Test.txt via the oC browser, the client shows Test.txt: Server does not support X-OC-MTime

• 4.) Delete the file (Same behavior with latest tarball)

  Issue 2 created two files, which were visible via oC Browser, test.txt and Test.txt.
  After deleting successfully via the browser Test.txt, the file test.txt remained. That file is visible in the Browser but not on the client side. On the browser side, marking the file and deleting it did not succeed and the file remained (no error). A browser refresh does not trigger/change anything on the client side.
  Forcing the client to sync, forced the server to remove the file. After a browser refresh, the file is not longer visible.

[davitol]

@mmattel

* Issue 2 created two files, which were visible via oC Browser, test.txt and Test.txt.

Are those 2 files hosted in your DropBox mount? Does your Dropbbox support case sensitive?

[mmattel]

No, that was via the browser and the backend is Linux where this is possible. Then, syncing with DB gets confused.

For DB naming rules please see https://www.dropbox.com/en/help/syncing-uploads/files-not-syncing

I filed issues with naming rules for client and core which would at least help in avoiding/minimizing such cases.

owncloud/core#29759 ([Feature Request] Check if file names restrictions apply for a given mount (filesystem))
owncloud/client#6202 ([Feature Request] Mark filenames with problematic characters or patterns)

[ckamm]

@davitol To check whether this might be a general client bug, I tested case "2.) Lowercase II" on Win10 against a server using standard linux filesystem storage. The case-rename is propagated correctly in that case, no extra files appear for me.

For now I assume this is something that can be solved in the dropbox app. If there's something the client could do to help, let me know.