[Pkg-owncloud-maintainers] Bug#804651: owncloud: renaming a folder can destroy all contained files

[Cyrille Chépélov]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/attachments/20151116/f9c40694/attachment.html>