Hi David,
>> 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. > What are the clients (platform, version number) used to synchronize? Here's the output of cat access.log|cut -d " " -f 12- |sort |uniq "-" "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)" "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)" "CardDAV-Sync/0.4.19 (LGE; g3_global_com; Android 4.4.2; fr_FR; org.dmfs.carddav.Sync/139)" "gvfs/1.24.1" "iOS/9.1 (13B143) dataaccessd/1.0" "Mac OS X/10.10.5 (14F27) AddressBook/1579" "Mozilla/5.0 (Linux) mirall/2.0.0" "Mozilla/5.0 (Linux) mirall/2.0.2" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 Lightning/4.0.3.1" "Mozilla/5.0 (Macintosh) mirall/2.0.2" "Mozilla/5.0 (Windows) mirall/1.4.2" "Mozilla/5.0 (Windows) mirall/2.0.1" "Mozilla/5.0 (Windows) mirall/2.0.2" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 Lightning/4.0.3.1" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 Lightning/3.3.7" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 Lightning/3.3.2" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 Lightning/4.0.2.1" > Have you checked upstream issue tracker already for similar issues? Yes, with no results. 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. > > 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?). We've been burned multiple times, with no apparent distinction between the initiating owncloud-client platform (Windows, Linux, Mac). It /is/ 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). 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. -- Cyrille