Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Client creates conflict files when hidden files are not to be synced... #4023
... although no file or folder is actually hidden.
A changed file should be uploaded to the server.
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.
Operating system: Debian 8.2
Web server: Apache 2.4
PHP version: 5.6
ownCloud version: 8.1.2
Storage backend: Local
Client version: 2.0.2
Operating system: Windows 8.1
OS language: German
Installation path of client: C:\Program Files (x86)\ownCloud
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
@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
So far my theory ;-)
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.
@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.
@Flexxxo Thanks for the hint.
However, I observed a rather weird behavior: