-
Notifications
You must be signed in to change notification settings - Fork 668
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 cannot sync shared file when edit privileges not exist. Files out of sync #1448
Comments
ok, the bug is actually the file is not going to be restored after it was deleted locally. Lock: that is not possible. There is no way to create locks that can be forced to other apps. |
@dragotin That's fine as well. As long as the file is restored from the server without having to delete anything. |
@ser72: wait, is that 1.5.1? |
@dragotin Yes 1.5.1 |
@dragotin Understand the fix put into place. The user, however, desires to know:
|
|
@dragotin @MTRichards Is there any plan to have the server transmit that information so the Client can make the file read only? If so, what release is it planned for? |
Tracked in server issue owncloud/core#6983 |
After quitting ownCloud client and deleting csync_journal and restarting the client, the files synced and I had conflict files. However, I shouldn't have to do that. Users won't know that trick |
Really? Can you please send the client log? @dragotin: the server task is owncloud/core#3602 , not the one you mentioned. |
In 1.5.2 client, the logs are as follows:
Error is: Still no conflict or resync |
@ogoffart Logs sent a few days ago. Any updates on this issue? |
Important part:
What is the size in bytes of |
Shared/share me/test,txt is a small text file with one or two lines in it of total about 8 characters. Don't have the exact file I used anymore, but I would say about 4-8 bytes total |
can you verify that the file .test.txt.~4823 in your local folder contains 4 bytes and is exactly the same as the one in the server? |
I think the problem is that the propagator beleive the the file has the new size, and therefore tries to download more. |
I will have to retest as the initial setup is lost. Will try to get to it this afternoon |
Here is a hack for it: https://cpaste.org/pebanlqqt The problem is that this whole Shared/ workaround is just a hack and we try to recover things without having all the information we need to recover. The long term goal would be that the server advertise which paths are read only, so we can, in the updater phase know to restore the file rather than try to upload it, see that there is an error, then try to recover. |
@ogoffart Any update on this? I have a call on Wednesday with this user and need to have an update. |
The work around is to delete the modified file (or move it elsewhere) and mirall will then restore the original. We'll maybe apply that workaround patch in a newer version of the client. We will be able to do a proper fix when the server tells us which directories are read only. |
The problem is the client doesn't know there was a problem. And once they realize it, they can't seem to correct it without deleting the .cysnc.journal file. The user would like to have this "automated". A fix like what we thought was put into place where the modified file on the client is made into a conflict file and the file synced from the server is "acceptable" -- though ideally this client would like to not be able to edit the file on the client device. |
@ogoffart Is it safe to apply the patch for 1.6? If so, please commit it now. |
We do not know the _modtime from the server, at this point, so just set the current one. (rather than the one locally)
We do not know the _modtime from the server, at this point, so just set the current one. (rather than the one locally)
What exactly does this patch do? I just tested in 1.6.0 Beta 1 and the errors are as follows: The file doesn't sync, as expected, an error appears one time. No conflict is created. The files are still out of sync. I thought when this occurred, the edited version from the client would be turned into a conflict file and the original version from the server will be downloaded to the client? |
the problem seems now that you get the error that caused the previous error to appear in the first place. the error says it all. (Maybe the temporary file need to be opened by mirall in a exclusive mode on windowse. @guruz ? ) |
Client logs:
|
@ogoffart Any updates on this issue? |
I just tested this with 1.6.0 beta2 on both Linux and Windows: The edited files is copied to a conflict file and the original version of the file is restored. It works as expected. Please reopen if this bug if that does not work for you with 1.6.0. Thanks. |
👍 |
I have alot of server replied forbiddens in my logs. I can get the sync going if I reset the file permissions on those files/folders. Both the server and the clients (1.6.0rc2) are Debian Jessie. Sometimes the same files says "of ther specified Etags not matched" thanks |
Steps
ISSUE
Now there are 2 versions of this file. User B cannot get his file to sync back with the ownCloud server.
User B deletes the file from his PC and still gets 403 FORBIDDEN and the file is not downloaded to his PC.
WORK AROUND
The unacceptable work around is to delete the .csync_journal file and then the file will resync (can take up to 5 minutes for the sync to occur)
This is unacceptable as the normal user won't know to delete this file and wait.
Request
When a file is shared without edit privileges, place some sort of lock on the file on the PC so that a user cannot edit/save the file creating an out of sync scenario.
The text was updated successfully, but these errors were encountered: