Client trying to sync deleted File

[Turbocube644]

The Client (1.8.0 beta1) tries to sync a file, which has been deleted. It shows the following error: "Error downloading [filename] - Server replied: Not found". The file neither exists on the server nor the local computer. This happens for multiple files, that have been deleted.
For some classes, I often get a Timeout.
The server ist still 7.0.4 (because the update routine thinks it is the newest version)

[guruz]

@Turbocube644 Is there anything about the filename or the directory it is stored in that could help us to track this down?

Special characters?
External storage on server?
Which DB on the server?

[Turbocube644]

The file name only consists out of ASCII letters, so no special characters.
The directory is no external storage, but the file is part of a git repository.
I'm using a mysql database.

[guruz]

@icewind1991 @PVince81 A server file scanner issue?

[PVince81]

Can you check the database: select * from oc_filecache where path like '%thedeletedfilename%' ?

[Turbocube644]

I checked the database: the query returns zero entries.

[PVince81]

@guruz seems not. If the file is neither on disk nor in the oc_filecache, the server should not know anything about it and return 404.

How would the client behave ? What if it's trying to resume a failed download on a file that was deleted ? (just wild guess)

[guruz]

What if it's trying to resume a failed download on a file that was deleted ?

Should not happen here, if the file was not discovered the download will not be attempted to resume.
CC @ogoffart

@Turbocube644 Are you 100% about that DB query results? Also about if the file maybe exists on your server hd?

[Turbocube644]

Yes, I'm 100% sure about the DB query results. I checked them twice.
I just had a look at the server hd: the file does not exit there.

[dragotin]

Do you find an entry about the file in the apache access_log? That entry would be interesting.

[Turbocube644]

Unfortunately I don't have access to the logs...

[dragotin]

@Turbocube644 ok, please create a client log file that shows a sync run where your client tries to download the files.

[Turbocube644]

the files is pretty big...
http://cloud.turbocube.org/public.php?service=files&t=9ff933755171bac198a7b09d60549bd4

[ckamm]

@Turbocube644 Thanks for the log! That's interesting.

The whole sync failed because of a timeout when trying to delete workspace/.metadata/.plugins/org.eclipse.core.resources/.history/6b/b0c2edc09db40014111b916fb9f5489a from the server. That file is found on the server - is that correct?

The confusing messages saying 'Error downloading ...' are actually about DELETE requests to the server failing.

But then there's also a file ending in c06771af7ab50014115594bbc2625284 that shows up only in the remote reconciliation logs (why is it assumed to be on the server?). Marking this as REMOVE and trying to delete it is bound to cause trouble.

[ckamm]

The etag for the directory that contains c06771af7ab50014115594bbc2625284 didn't change, which is why the remote discovery assumes the file is still present and attempts to delete it.

[ckamm]

We're considering whether to make 404 on DELETE a non-fatal error that deletes the file from the DB. But it won't be in 1.8.0.

[ckamm]

With the patch applied I no longer get stuck files in this situation.

[guruz]

The etag for the directory that contains c06771af7ab50014115594bbc2625284 didn't change, which is why the remote discovery assumes the file is still present and attempts to delete it.

Hold on.. something for @PVince81 ?

[guruz]

@dragotin OK to cherry-pick the above commit into 1.8 for rc2? It's a gold ticket

[PVince81]

Is it a file inside a shared folder ? Is the user seeing the bug a recipient or owner ? Is the shared folder inside a subfolder ? If yes, it could be the cross-storage etag propagation issue.

[dragotin]

Yes, please pick the patch now.

[ckamm]

Merged into the 1.8 branch now.

[ckamm]

@Turbocube644 The patch was merged, could you test it with tomorrow's build at http://download.owncloud.com/desktop/daily/ ?

[guruz]

@Turbocube644 Could you still reply to the questions in #2919 (comment) ?
Thanks

[Turbocube644]

No, it wasn't inside a Shared folder.
Unfortunately my owncloud instance completly crashed while updating to 8.0.2 and I therefore had to reset completly (the backup didn't work). Now After resyncing I didn't get the problem again.

[ckamm]

Okay! Closing since the patch fixed it when I reproduced the problem.

[rienesl]

Just to give an update:
I have the same problem. Having updated to 8.0.2 on the server side helped nothing. I'm using the 1.8.0 client. It happens, after I renamed a directory. Since then, I get the error on all the clients, . Pressing F5 for rebuilding the index did not help. I'm using a productivity system, so I'm not able to try the daily-built test.
My suggestion would be: If a deletion request returns "not found" then remove it from the database (the goal of deleting it was to remove it anyway...).