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

download again unchanged files #721

Closed
JacekZ opened this issue Jun 26, 2013 · 3 comments
Closed

download again unchanged files #721

JacekZ opened this issue Jun 26, 2013 · 3 comments

Comments

@JacekZ
Copy link

JacekZ commented Jun 26, 2013

Hello,
I am using windows sync client 1.3. I have noticed that sync client sometimes downloads again unchanged file to my computer. There is no conflict, just download again.

Below, there is sync-client's log for file: _MG_8837.jpg

06-26 15:48:25:805 csync_vio_stat: Win32: STAT-inode for C:\Users\Jacek\Pictures/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg: 52236
06-26 15:48:25:805 csync_ftw: Uniq ID from Database: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg -> 51c9a3d97fdc6
06-26 15:48:25:805 csync_walker: file: C:\Users\Jacek\Pictures/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg
06-26 15:48:25:805 _csync_detect_update: ==> file: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg - hash 161899250193936076, mtime: 1358180383
06-26 15:48:25:805 _csync_detect_update: Database entry found, compare: 1358180383 <-> 1358180383, md5: 51c9a3d97fdc6 <-> 51c9a3d97fdc6
06-26 15:48:25:805 _csync_detect_update: file: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg, instruction: INSTRUCTION_NONE <<=

What could be the problem? I noticed same behavior on Linux client.

@JacekZ
Copy link
Author

JacekZ commented Jun 26, 2013

OK, file _MG_8837.jpg appears in log few times:

06-26 15:48:34:057 oc_module: owncloud_stat ownclouds://host.com/remote.php/webdav/obrazy/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg called
06-26 15:48:34:057 csync_walker: file: ownclouds://host.com/remote.php/webdav/obrazy/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg
06-26 15:48:34:057 _csync_detect_update: ==> file: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg - hash 161899250193936076, mtime: 1358180383
06-26 15:48:34:057 _csync_detect_update: Database entry found, compare: 1358180383 <-> 1358180383, md5: 51cae9d88c6b2 <-> 51c9a3d97fdc6
06-26 15:48:34:057 _csync_detect_update: file: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg, instruction: INSTRUCTION_EVAL <<=

06-26 15:48:40:001 _csync_merge_algorithm_visitor: INSTRUCTION_NONE file: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg

06-26 15:48:40:157 _csync_merge_algorithm_visitor: INSTRUCTION_SYNC file: wesele_podroz/reportaz2_msstudio/_MG_8837.jpg

06-26 15:48:51:935 oc_module: => open called for ownclouds://host.com/remote.php/webdav/obrazy/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg
06-26 15:48:51:935 oc_module: GET request on /remote.php/webdav/obrazy/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg
06-26 15:48:51:935 oc_module: Sendfile handling request type GET.
06-26 15:48:51:935 oc_module: -- GET on ownclouds://host.com/remote.php/webdav/obrazy/wesele_podroz/reportaz2_msstudio/_MG_8837.jpg
06-26 15:48:52:169 oc_module: Content encoding ist with status 200

@JacekZ
Copy link
Author

JacekZ commented Jun 28, 2013

Ok, be more specific. Maybe its server site problem.

Expected behaviour

Download only changed files.

Actual behaviour

I've got running two sync-clients (windows vista and fedora 17). The clients sync 3 directories (12GB). Everything works fine - every sync-client send proper propfind commands (one for each monitoring directory) to server. Suddenly clients start to send propfind command to each subdirectories and then start to download particular files.

No conflict files, just download and overwrite original files.
No changes has been made on clients and servers!

I made some research. I noticed that file's etag changed on server and client download files. I don't know who and how files are changed :( I'm only person which has access to my account (no shared files).

My issue is very similar to #701

Steps to reproduce

  1. Run two sync-clients
  2. Try to log into your owncloud server
  3. Do what you want (but don't upload/change any files)
  4. Wait (non deterministic period of time)
  5. Sync-clients should start to download unchanged files.

Server configuration

Operating system:
Rhel 6.4

Web server:
apache 2.2.15

Database:
mysql

PHP version:
5.3.3

ownCloud version:
5.0.7 (stable5)

Storage backend:
GFS2 (Global file system)

Client configuration

Client version:
1.3
Operating system:
Win Vista, Fedora 17

OS language:
Polish

Installation path of client:
Standard :)

Logs

  1. Output of owncloud --logdir owncloud_log.

    Below you can noticed that md5 was changed:

06-28 10:30:34:180 csync_ftw: Uniq ID from Database: plener/_MG_8978.jpg -> 51cbe47cc0f84 06-28 10:30:34:180 csync_walker: file: /home/jacek/Obrazy/plener/_MG_8978.jpg 06-28 10:30:34:180 _csync_detect_update: ==> file: plener/_MG_8978.jpg - hash 9922413772296144077, mtime: 1358431360 06-28 10:30:34:180 _csync_detect_update: Database entry found, compare: 1358431360 <-> 1358431360, md5: 51cbe47cc0f84 <-> 51cbe47cc0f84 06-28 10:30:34:180 _csync_detect_update: file: plener/_MG_8978.jpg, instruction: INSTRUCTION_NONE <<= (...skip...) csync_walker: file: ownclouds://host.com/remote.php/webdav/obrazy/plener/_MG_8978.jpg 06-28 10:30:45:034 _csync_detect_update: ==> file: plener/_MG_8978.jpg - hash 9922413772296144077, mtime: 1358431360 06-28 10:30:45:034 _csync_detect_update: Database entry found, compare: 1358431360 <-> 1358431360, md5: 51cd48f183e85 <-> 51cbe47cc0f84 06-28 10:30:45:034 _csync_detect_update: file: plener/_MG_8978.jpg, instruction: INSTRUCTION_EVAL <<= 06-28 10:30:45:034 oc_module: Skipping target resource. 06-28 10:30:45:034 oc_module: closedir method called 0x7f25a448d450!

  1. Web server error log:
    Nothing interesting (no error)
  2. ownCloud log (data/owncloud.log):
    Nothing interesting (no error)

@dragotin
Copy link
Contributor

dragotin commented Oct 4, 2013

Yes, there have been some server problems leading to this problems. Let me close this bug now, please comment in #994 about this problem.

@dragotin dragotin closed this as completed Oct 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants