OCC does not retry sync on failure

[knebb]

Hi all,

I am running OC (2.7.6 - 3261) client on Windows (v20H2- 19042.985) and the connected OC server is running 10.7.0 (on Linux).

I have configured a directory to sync and it really runs fine so far.

Now I have the following:
I create a new file (ie an image *.png) and edit it (with mspaint). OC client can not sync because the file is locked. That’s fine so far. Now I am done with editig, the new file is safed and no lock should be there.

I expect OC client trying to sync the file on the next invocation so it gets synced to the server. Instead OC client does never touch the file again and it will stay unsinchronized. Additionall,y I can find the file in the “Activity” tab as “not synchronized”.

Same happens for all files which are locked during an attempt to sync them.

So any new files doe not get synchronized and any edited ones either not.

I expect this is not how it should work.

Her’s the part of the logfile where the file occured the first time:

05-20 11:03:57:877 [ info sync.discovery ]:	Not a move, no item in db with inode 69651
05-20 11:03:57:877 [ info sync.discovery ]:	Discovered "Arbeitszeugnis Peggy.odt" CSyncEnums::CSYNC_INSTRUCTION_NEW OCC::SyncFileItem::Up CSyncEnums::ItemTypeFile
05-20 11:03:57:877 [ info sync.engine ]:	Item is on blacklist:  "Arbeitszeugnis Peggy.odt" retries: 8 for another 2283 s
[...]
05-20 11:03:58:762 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:ERROR:C:\\Users\\chvoelker\\Documents\\Arbeitszeugnis Peggy.odt" to QLocalSocket(0x260c0b6c990)
[...]
05-20 11:04:00:763 [ info sync.propagator ]:	Starting CSyncEnums::CSYNC_INSTRUCTION_IGNORE propagation of "Arbeitszeugnis Peggy.odt" by OCC::PropagateIgnoreJob(0x260c47e87b0)
05-20 11:04:00:763 [ warning sync.propagator ]:	Could not complete propagation of "Arbeitszeugnis Peggy.odt" by OCC::PropagateIgnoreJob(0x260c47e87b0) with status OCC::SyncFileItem::BlacklistedError and error: "Server hat \"403 Forbidden\" auf \"PUT https://owncloud.knebb.de/remote.php/dav/files/cvoelker/Doks/Arbeitszeugnis Peggy.odt\" geantwortet (Sabre\\DAV\\Exception\\Forbidden) (Übersprungen aufgrund des früheren Fehlers, erneuter Versuch in 38 Minuten)"

Well, it writes “retry in 38Minutes”. But it does not. It might retry but will fail because on “blacklist”- which blacklist? I do not have excluded the file!

Is this a bug? Can someone confirm?

Thanks!

/KNEBB

1. Client logfile: Output of owncloud --logwindow or owncloud --logfile log.txt
   (On Windows using cmd.exe, you might need to first cd into the ownCloud directory)
   (See also http://doc.owncloud.org/desktop/2.2/troubleshooting.html#client-logfile )

2. Web server error log:

3. Server logfile: ownCloud log (data/owncloud.log):

[michaelstingl]

@knebb log lines are about a *.odt file and a server error. Nothing about a *.png and local lock because of editing in mspaint. Could you post the correct log lines?

[knebb]

Hi,

then *png was just an example. I happens for any other type of files. So it happened recently for the above shown *odt file.
As my memory lasts longer than the logfile I do not have the entries of the *png, instead of *odt. So it is the same. Doe not matter if png or odt.

/KNEBB

[michaelstingl]

No real difference between odt or png, but difference between local locking or server 403 error. To understand the local locking problem, please find the related lines.

[knebb]

Hi,

ok, I did some further research on this issue. You are right- it had nothing to do with local locks. Instead I got the 403 errror from the webserver which I did not understand at all.
On a freshly created sync folder the issue did not appear.

So I checked the directory structure and I noticed something strange.
The data directory holds my user files and the web frontend showed everything was fine. My local directory was configured to sync to /Doks on the OC server. However, there was no Doks folder in trhe filesystem- only a Dokumente. So somehow OC (server or client) mixed the directory structure up. On new files it appears trying to sync to Doks which was not found. Existing files synced to Dokumente which was fine.

I now removed the sync entry in OC client, removed the related folders in web GUI and created a new sync. Now everything is syncing fine.

But I still have the Dokumente folder in my data directory. Is it safe to simply do a rm -rf Dokumente or are there any references in the database? If so, how can I find and remove them from DB?

Thanks!

/KNEBB

[knebb]

Finally I am fine again here. As mentioned I had some orphaned folders in the filesystem which did not appear on the web GUI. I did a sudo -u www-data /srv/www/occ files:scan <USERNAME> --repair and the folders appeared in the web GUI where the user was able to deleted them. Thy are gone now in the filesystem, too.