Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Same files on different PC not detected -> downloading again #1282

Closed
Pro opened this issue Dec 13, 2013 · 6 comments
Closed

Same files on different PC not detected -> downloading again #1282

Pro opened this issue Dec 13, 2013 · 6 comments
Assignees

Comments

@Pro
Copy link
Contributor

Pro commented Dec 13, 2013

I've set up my Notebook with OC client 1.5 and synced all the local files to OC6 server.
Then I copied the files over LAN to my Desktop-PC and set up OC client 1.5 here too.

Expected behaviour

The client on the Desktop PC should detect that the files on the server are the same as the local ones and thus shouldn't download them from the server agian (e.g. by comparing checksums).

Actual behaviour

The client on the Desktop PC says that the files on the server are new and therefore downloads all the files from the server even if the local ones are exactly the same.
This only happens for the first sync initialization After all the files are synced (downloaded) once, it works like it should.

Steps to reproduce

  1. Set up folder on PC1 and sync to the server using OC client 1.5
  2. Copy the same folder to PC2
  3. Set up OC client 1.5 on PC2 and add the copied folder
  4. OC client on PC2 download all the files again from the server and overwrites the local ones

Server configuration

Operating system: Ubuntu 10.04.4 LTS

Web server: Apache/2.2.14

Database: MySQL 5.1.72

PHP version: 5.4.22

ownCloud version: OC6

Storage backend: Files, Encryption App enabled

Client configuration

Client version: 1.5.0 (final)

Operating system: Windows 8.1 x64

OS language: German

Installation path of client: default

Logs

Here some entries of the log window:

12-13 15:21:52:261 _csync_detect_update: file: MyDir.lrdata/8/845A/845AE663-8F1F-4F55-9908-A7ECF6599AD9-077b070982fd42045ed5e932196fb988.lrprev, instruction: INSTRUCTION_NEW <<=
12-13 15:21:52:261 oc_module: closedir method called 0b489578!
12-13 15:21:52:261 csync_ftw:  <= Closing walk for ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/845A with read_from_db 0
12-13 15:21:52:262 oc_module: owncloud_stat ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/844A called
12-13 15:21:52:262 csync_walker: directory: ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/844A
12-13 15:21:52:262 _csync_detect_update: ==> file: MyDir.lrdata/8/844A - hash 11689532646321692401, mtime: 1386589323, fileId: 00055320oc76a7ceb236
12-13 15:21:52:262 csync_statedb_get_stat_by_hash: No result record found for phash = 11689532646321692401
12-13 15:21:52:263 _csync_detect_update: file: MyDir.lrdata/8/844A, instruction: INSTRUCTION_NEW <<=
12-13 15:21:52:263 oc_module: opendir method called on ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/844A
12-13 15:21:52:465 oc_module: Simple propfind result code 207.
12-13 15:21:52:465 oc_module: opendir returning handle 0b4895b8 (count=2)
12-13 15:21:52:465 oc_module: owncloud_stat ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/844A/844A543A-E8ED-4B10-8102-3C5E12F42A90-077b070982fd42045ed5e932196fb988.lrprev called
12-13 15:21:52:465 csync_walker: file: ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/844A/844A543A-E8ED-4B10-8102-3C5E12F42A90-077b070982fd42045ed5e932196fb988.lrprev
12-13 15:21:52:466 _csync_detect_update: ==> file: MyDir.lrdata/8/844A/844A543A-E8ED-4B10-8102-3C5E12F42A90-077b070982fd42045ed5e932196fb988.lrprev - hash 11485440105041598876, mtime: 1380661659, fileId: 00055321oc76a7ceb236
12-13 15:21:52:466 csync_statedb_get_stat_by_hash: No result record found for phash = 11485440105041598876
12-13 15:21:52:467 _csync_detect_update: file: MyDir.lrdata/8/844A/844A543A-E8ED-4B10-8102-3C5E12F42A90-077b070982fd42045ed5e932196fb988.lrprev, instruction: INSTRUCTION_NEW <<=
12-13 15:21:52:467 oc_module: closedir method called 0b4895b8!
12-13 15:21:52:467 csync_ftw:  <= Closing walk for ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/844A with read_from_db 0
12-13 15:21:52:467 oc_module: owncloud_stat ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/840D called
12-13 15:21:52:467 csync_walker: directory: ownclouds://owncloud.example.com/remote.php/webdav/Daten/MyDir.lrdata/8/840D
12-13 15:21:52:467 _csync_detect_update: ==> file: MyDir.lrdata/8/840D - hash 18258541583847637725, mtime: 1386589322, fileId: 00055318oc76a7ceb236
12-13 15:21:52:467 csync_statedb_get_stat_by_hash: No result record found for phash = 18258541583847637725
12-13 15:21:52:468 _csync_detect_update: file: MyDir.lrdata/8/840D, instruction: INSTRUCTION_NEW <<=
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1384456-same-files-on-different-pc-not-detected-downloading-again?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github).
@csware
Copy link
Contributor

csware commented Dec 13, 2013

Same happens if you update the timestamp of a file w/o modifying a file or if you copy a file.

@a-schild
Copy link

This is a problem, since the status of the local replica is stored in the local database. Currently the server does not a checksum/hash calculation. When the server could calculate the sha hash for a file, then we could prevent redownload of the file.

@guruz
Copy link
Contributor

guruz commented Apr 19, 2017

FYI @IljaN @ogoffart @ckamm

@ogoffart
Copy link
Contributor

closing old issue.
This should normaly be fixed now, we compare the size and mtime of file that are new. And we don't download them.

@guruz
Copy link
Contributor

guruz commented Apr 21, 2017

@ogoffart It's not fixed. :)

This issue here is about the desktop client computing the file hash of the existing local file and comparing it with what it sees on the server. It should then see that the server had stored an idential file (according to size+hash, not according to size+date) and then just update the local sync DB.

@guruz guruz reopened this Apr 21, 2017
@guruz
Copy link
Contributor

guruz commented Apr 21, 2017

Closing as duplicate of #3422

@guruz guruz closed this as completed Apr 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants