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

Client creates conflict files when hidden files are not to be synced... #4023

Closed
raimund-schluessler opened this issue Oct 28, 2015 · 11 comments

Comments

@raimund-schluessler
Copy link

commented Oct 28, 2015

... although no file or folder is actually hidden.

Expected behaviour

A changed file should be uploaded to the server.

Actual behaviour

The client does not upload the changed file, instead he creates a conflict file and restores the changed file from the server. In the client activity log it says "the upload of this file is not allowed, because it is write protected at the server, restoring" (translated from German string).

I checked if this file is really write protected which it is not. If I manually delete the restored file and rename the conflict file, the client does upload it to the server. With the next change to the file, again a conflict file is created with the same error log.

Steps to reproduce

Happens since I updated to client v2.0.0.
Hard to tell how to reproduce this, because it does not happen to every file. Some files are uploaded without a problem. It looks like it only happens to files without a file extension, but I am not sure about this. I will watch the behaviour and report the findings.

Server configuration

Operating system: Debian 8.2

Web server: Apache 2.4

Database: MySQL

PHP version: 5.6

ownCloud version: 8.1.2

Storage backend: Local

Client configuration

Client version: 2.0.2

Operating system: Windows 8.1

OS language: German

Installation path of client: C:\Program Files (x86)\ownCloud

Logs

During logging the file "Source/.git/index" was changed. It seems to be restored at https://gist.github.com/raimund-schluessler/97e723326a77ce4db9d7#file-gistfile1-txt-L4229

  1. Output of owncloud --logwindow or owncloud --logfile log.txt
    https://gist.github.com/raimund-schluessler/97e723326a77ce4db9d7
  2. Web server error log:
    Will hand in later
  3. ownCloud log (data/owncloud.log):
    Will hand in later
@raimund-schluessler

This comment has been minimized.

Copy link
Author

commented Oct 29, 2015

I found out, that these problems do not occur if I allow to sync hidden files. This is fairly confusing as neither the folder nor any of the files within are actually hidden.

I changed the title accordingly.

@raimund-schluessler raimund-schluessler changed the title Client creates conflict files for changed files Client creates conflict files when hidden files are not to be synced... Oct 29, 2015

@guruz guruz added this to the 2.1-next milestone Oct 29, 2015

@dragotin

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2015

@raimund-schluessler we're talking about a file that is inside of a hidden dir (.git in this case) and got a local change, right? After the local change, the client tries to upload it but fails with a obviously wrong error message.

In the logfile we can see that the client detects a change for .git/index (line 4467) but in the line 7288, the remote discovery is not done for the folder .git because its ignored. That might lead to empty remotePerms for .git/index which than causes the error message in syncengine.cpp line 1000.

So far my theory ;-)

@raimund-schluessler

This comment has been minimized.

Copy link
Author

commented Oct 29, 2015

@raimund-schluessler we're talking about a file that is inside of a hidden dir (.git in this case) and got a local change, right? After the local change, the client tries to upload it but fails with a obviously wrong error message.

Yes, correct.

Your theory sounds reasonable so far. This would explain, why it does work if syncing hidden files is allowed.

Is every folder beginning with a dot (.) considered hidden? Because in the folder preferences it is not marked as hidden.

@ckamm

This comment has been minimized.

Copy link
Member

commented Oct 29, 2015

@raimund-schluessler It works fine for me with master on linux.

You're on Windows though and we've found an inconsistency in how we treat dot-prefixed files on Windows. We're looking into it, thanks for reporting!

Considering files that start with a dot as hidden is a convention from the unix world.

ckamm added a commit that referenced this issue Oct 29, 2015

Hidden files: Consider .* hidden everywhere #4023
This seems to be the only place where we did this only on
non-windows OSes.

@ckamm ckamm self-assigned this Oct 29, 2015

@ckamm ckamm added the ReadyToTest label Oct 29, 2015

@ckamm

This comment has been minimized.

Copy link
Member

commented Oct 29, 2015

I've tested the new version on Windows and it works correctly for me. @raimund-schluessler could you test the windows nightly tomorrow (current one doesn't have the patch). You can get them from here: http://download.owncloud.com/desktop/daily/

@raimund-schluessler

This comment has been minimized.

Copy link
Author

commented Oct 29, 2015

Thanks for your effort!

@raimund-schluessler

This comment has been minimized.

Copy link
Author

commented Oct 29, 2015

@ckamm I will test it tomorrow.

@raimund-schluessler

This comment has been minimized.

Copy link
Author

commented Oct 30, 2015

There seems to be no nightly build for 20151030 yet.

@Flexxxo

This comment has been minimized.

Copy link

commented Nov 2, 2015

There's one for Oct 31st and Nov 2nd available now.

@raimund-schluessler

This comment has been minimized.

Copy link
Author

commented Nov 2, 2015

@Flexxxo Thanks for the hint.

Using 2.1.0.5597-nightly20151102:
The client creates no conflict files anymore when "Sync hidden files" is disabled. The files e.g. in a ".git" folder are just not synced anymore, as one would expect (or not on windows ;).

However, I observed a rather weird behavior:
When I enable "Sync hidden files" again, all hidden files are uploaded again, although nothing has changed during the period when they where not synced. @ckamm Is this an expected behavior?

@Dianafg76 Dianafg76 removed the ReadyToTest label Nov 10, 2015

@ckamm

This comment has been minimized.

Copy link
Member

commented Nov 10, 2015

@raimund-schluessler It sounds like the client should discover that the files already exist on the server and not upload them again. I'll move this to a new ticket. Thanks for testing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.