File corruption

[chandon]

Expected behaviour

I create a file in a folder shared with Owncloud and it always upload a correct file (not corrupted)

Actual behaviour

When I create a file in a folder shared with Owncloud it sometimes uploads a corrupted file. The file has the same size as the original one, but is corrupted. If it can help, i've uploaded 2 corruption examples here:
https://www.wetransfer.com/downloads/499390103af226851e2ea96237d5487620141029092303/efdb625623a454be881d013a02c10e3e20141029092303/b2bcb7

The original files have been created in the owncloud folder on purpose to test the bug. The corrupted files have been downloaded directly from the server folder /var/www/owncloud/data/test/files

Possibly the same bug as #1969 ?

Steps to reproduce

It's a ramdom bug...
I've past massivly 50 files in my owncloud folder, then i did a md5sum on the server to find the corrupted files among all of them

Server configuration

Operating system: Ubuntu 14.04 LTS server
Web server: Apache 2.4.7-1
Database: MySQL 5.5.37-0ubuntu0.14.04.1
PHP version: 5.5.9-1ubuntu4.3
ownCloud version: 7.0.2(stable)

List of activated apps:
Default apps (i don't use them)

Client configuration

Client version: 1.6.4 build 1195

Operating system: Mac Osx Maverick (we are 2 having the same problem)

[LukasReschke]

@PVince81 I think that might be of interest to you?

[PVince81]

@chandon did you enable encryption on the server ?

[chandon]

No, as you can see in my description, the examples files are directly downloaded from the server (so they are not encrypted).

A binary compare show that the first 0x4000 bytes are corrupted... like a bad "part" included at the beginning of the corrupted files. You can find the same part later in the file

[PVince81]

Verrry weird. This guy also had the exact same issue but with encryption enabled: see owncloud/core#10975 (comment)

CC @VincentvgNn

I'm suspecting a concurrency / race condition issue... You could try installing and enabling the "files_locking" app.

[guruz]

Do you have the corrupted file open in any application?

[chandon]

no, it's just a copy/paste from my mac osX desktop to the owncloud folder, that's all. neither the desktop files or destination files are open in any application (i don't have virus tool or apps like that, only owncloud accessing files in background)

[ckamm]

I think this could possibly be the client's fault. In 1.7 we avoid uploading files that were changed too recently, but in 1.6 the following could happen:

• Copy many files into a sync folder on the client side
• The file system watcher triggers a new sync while copying is ongoing
• Then we want to upload a file and call read() on it several times while its copy operation is ongoing.

On the other hand I think it's odd that the file ends up having the right size and that we consistently see the first 16kb being replaced by a later 16kb chunk of the same file. I don't see a reason why the first read() would go wrong in this particular way, but it might happen. It could also be a server bug.

I'll try to reproduce this locally with the 1.6 branch. @chandon maybe you could try whether you still see the issue with the files_locking ownCloud server plugin installed? And if you can, attempting to reproduce the issue with a 1.7 client would also be appreciated - if it's reproducible there it's much more likely to be a server issue.

[chandon]

I've installed the "files_locking" app for 2 days now. I've done a test, i didn't had any corrupted file (which doesn't mean that the problem is solved...). If we still have any corrupted file with the plugin, i'll let you know in a later comment

[ckamm]

@chandon Thank you!

I've tried it locally with 1.6 (on ext4, with SSD) using 50 copies of your test_ORIGINAL.pptx, but couldn't get a corrupt file in 10 attempts. I tried again with various levels of io and hdd load, but could not produce corrupt data. I also tried with 500 files; and with sleeping 100ms between each copy.

[ckamm]

@chandon Did you observe any more corruption?

[chandon]

@ckamm Yes, i did observe a corruption again, always with the MAC OSX Client sync, and with the files_locking enabled. Always the first 0x4000 bytes corrupted (corresponding to another block later...)
So the "files_locking" app doesn't help...