<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi David,<br>
      <br>
      <br>
    </div>
    <blockquote cite="mid:5641EB1A.3090101@tilapin.org" type="cite">
      <blockquote type="cite">
        <pre wrap="">  3. From a client's native file explorer (nautilus / Finder /
Explorer), rename the folder made in #1
  4. Result: at the end of the rename and once all machines have sync'd
back, some or all of the files contained within the folder have been
permanently destroyed.
</pre>
      </blockquote>
      <pre wrap="">
What are the clients (platform, version number) used to synchronize?</pre>
    </blockquote>
    Here's the output of cat access.log|cut -d " " -f 12- |sort |uniq <br>
    "-"<br>
    "CalDAV-Sync/0.4.27 (LGE; g3_global_com; Android 4.4.2; fr_FR;
    org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"<br>
    "CalDAV-Sync/0.4.27 (Sony; E2333; Android 5.0; fr_FR;
    org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"<br>
    "CardDAV-Sync/0.4.19 (LGE; g3_global_com; Android 4.4.2; fr_FR;
    org.dmfs.carddav.Sync/139)"<br>
    "gvfs/1.24.1"<br>
    "iOS/9.1 (13B143) dataaccessd/1.0"<br>
    "Mac OS X/10.10.5 (14F27) AddressBook/1579"<br>
    "Mozilla/5.0 (Linux) mirall/2.0.0"<br>
    "Mozilla/5.0 (Linux) mirall/2.0.2"<br>
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
    Gecko/20100101 Thunderbird/38.3.0 Lightning/4.0.3.1"<br>
    "Mozilla/5.0 (Macintosh) mirall/2.0.2"<br>
    "Mozilla/5.0 (Windows) mirall/1.4.2"<br>
    "Mozilla/5.0 (Windows) mirall/2.0.1"<br>
    "Mozilla/5.0 (Windows) mirall/2.0.2"<br>
    "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
    Thunderbird/38.3.0 Lightning/4.0.3.1"<br>
    "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
    Icedove/31.7.0 Lightning/3.3.7"<br>
    "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
    Icedove/31.8.0 Lightning/3.3.2"<br>
    "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
    Icedove/38.1.0 Lightning/4.0.2.1"<br>
    <br>
    <br>
    <blockquote cite="mid:5641EB1A.3090101@tilapin.org" type="cite">
      <pre wrap="">
Have you checked upstream issue tracker already for similar issues?</pre>
    </blockquote>
    Yes, with no results.<br>
    For the record, the issue was already happening in 6.x times (Debian
    wheezy packages) 12-18 months ago, while upstream was at 7.x. I had
    refrained to report at the time, for concern this might be
    disregarded as "obsolete debiannery" by upstream. I hereby apolgise
    for my irresponsibility.<br>
    <br>
    <br>
    <blockquote cite="mid:5641EB1A.3090101@tilapin.org" type="cite">
      <pre wrap="">

The issue might be in the client used where the renaming happened, but
in any other client used to synchronize the instance too, so it would be
nice to narrow it down (can you reproduce the issue with a Debian client
on the move side, and a Debian client on the other side for example, or
what combination provokes the issue?).</pre>
    </blockquote>
    We've been burned multiple times, with no apparent distinction
    between the initiating owncloud-client platform (Windows, Linux,
    Mac). <br>
    It <i>is</i> possible that the variety of clients accessing the
    system is a factor, as well as possible timing issues (some of the
    computers are away, ~150 millisecond from the central machine while
    others are local; and there are about 10K files for a total of about
    10GiB depending on users' permissions).<br>
     <br>
    So far we're really glad Apple Time Machine could save our day (as
    owncloud's own file history really doesn't help us go back deep in
    time when nested hierarchies are lost to this issue, hence the
    "permanently destroyed"), but it's kind of problematic to have to
    rely on that.<br>
    <br>
        -- Cyrille<br>
    <br>
  </body>
</html>