Un-deletable folders and "An If-Match header was specified, but none of the specified the ETags matched." error #23376
Comments
ownCloud log (data/owncloud.log)The ownCloud log is huge (more than 300mb). Here are the last lines. I can provide more if needed: |
|
Yesterday I also discovered this: #23373 @ThatClyde you could try the following:
If you try to delete the folder between the two sync cycles, I suspect that you'll get an etag collision due to that other bug. |
|
CC @MorrisJobke in case this popped up in other cases |
|
@ThatClyde but the fact that you couldn't delete the folders in the first place is strange, especially if deleting doesn't work in the web browser. |
|
Ok, turns out I can't reproduce the rename issue on 9.0.0. So what you're seeing might be something else. |
|
@ThatClyde I tried to reproduce it with the following steps:
Works for me, no issues. @ThatClyde would be good if you could try with similar steps. |
|
That was on OC v9.0.0 with owncloud-client-2.1.1-1.1.x86_64 |
|
First, thank you for formatting my information - much less of an eyesore. I disabled syncing with the client and have deleted the folders in ownCloud web-interface, after 10 minutes, they had not-reappeared. I then added the parent folder back as synced. It's been five minutes and the undeleteable folders are still gone. This makes me wonder if its more an issue with the client. I'd done something similar but hadn't waited very long. Before trying that, I deleted a copied folder through the web interface and it had re-appeared. In the log for the client there was this message: I now wonder if this might be a client issue, rather than the owncloud core. I am going to try your steps precisely, @PVince81 - I'll report back shortly. Yesterday, I could not replicate it. This is a sizeable deployment, and to my knowledge, these are the only folders it is happening to. |
|
EML files ? Are there people in your organization using Thunderbird ? There was a bug in Thunderbird (or was it Outlook?) where eml files were synced over and over again. However the fact that a file like EML is synced repeatedly is a problem. @ThatClyde can you check your access logs ? Try and find the "DELETE" operation that your sync client initiazed. Then check around that whether anyone else did a "PUT" of an EML file (or other) inside that same folder. |
|
@guruz did we eventually put a special workaround for the EML files thing ? |
|
I don't think anyone uses Thunderbird, and this is just a document store. However, on the entire server, the only files that appear to be affected are .eml files. Is the access log is the client log, correct? The only PUT I've found is OCC:PUTFileJob.
|
|
No, the access log is the web server's access log. On apache it's in /var/log/apache2/access_log. Not sure about nginx. |
|
@PVince81
Except, after you mentioned the .eml issue, some of the files that I put in the folders were test.eml. After the final step, the folders re-appeared, and the only files that came with it were the .eml files (I had one per folder). These are completely blank text documents that I changed the extension on. The server isn't writing anything to the nginx access_log. I'm looking into changing the logging level. |
|
Here are the steps to reproduce:
|
|
In the access log, I'm not finding any DELETE, but I do find plenty of the PUT. It's not coming from my client, but rather from one of the staffs' client.
|
ghost
assigned
|
@guruz does the desktop client contain any workarounds for eml files that could cause trouble ? @ThatClyde are the PUT requests from #23376 (comment) related to the eml test file you mentionned ? If that's the case, I suspect that these clients are repeatedly reuploading the "eml" files and creating a conflict at the time you're trying to delete. |
|
@PVince81 yes, the PUT files are related to my test eml file. I was able to resolve the problem for the original folder by unsharing it with all the users except myself, deleting the subfolders via explorer/the client. I waited about five minutes and added the group that had access back. It's been another 5/10 minutes and so far, the subfolders have not reappeared. Watching the client yesterday, it looked like there was constant activity up/down for the .eml files. |
That does sound like the known EML bug. The part I don't understand is, if you didn't setup any clients for your test users, who is reuploading the EML file constantly ? 👻 |
|
That is a really good question - especially since the user that was uploading the documents according to the access log should not have had access. So, I retested it. I verified the SMB folder only had the admin and the three test users (at some point, myself or one of the other admins appeared to have removed all the users from having access, which granted access to everyone), re-created sub-folders and fake files, including the "Test.eml" files. Deleted one folder via the web-interface and another locally. It worked as it should have. I was careful to follow the steps the first time around, so I'm not sure how this happened, but I am willing to chalk it up to my own error, since nothing else makes sense. At the very least, I'd have expected the folder deleted via the web-client to reappear due to my own over-active client, but it did not. If there's anything else you'd like me to test or try, please let me know. Is the bug you're referring to #3235, or another? |
|
Yeah, owncloud/client#3235 Maybe the users who had the file reuploaded were using older client versions ? |
|
Is it safe to assume "Mozilla/5.0 (Macintosh) mirall/2.0.2" indicates they're using 2.0.2? |
|
Yeah, that's the old client. Please make them upgrade to 2.1.1. The behavior you observed in this ticket is expected behavior, closing. |
|
Thank you, @PVince81 - I really appreciate it. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to reproduce
I am uncertain how to reproduce this bug. It is only happening with two specific folders
Expected behaviour
The folders should then disappear on the actual share, the browser, and in explorer (via the client)
Actual behaviour
The folders will disappear briefly, then reappear. I tried re-naming the folders (appending -Copy), in the hopes that it would update the etag (as suggested on a github bug report), and I moved the folders out, then back in (as suggested here: owncloud/client#1767). I now have 2 of each of the folders, and I cannot delete them.
On the chance that it was an issue related to folder-renaming vs. file renaming, I renamed all the files via Windows Explorer in one folder to start "OLD-". About 2 minutes later, it populated the folder with the original files. The web-interface shows both the old and the new files.
I also created a new file in that folder. It appeared elsewhere, but when I changed its name, it changed everywhere without a duplicate, and when I deleted it, it properly disappeared.
Server configuration
Operating system:
RHEL 7.2
Web server:
Nginx
Database:
MariaDB
PHP version:
5.6.16
ownCloud version: (see ownCloud admin page)
9.0.0
Updated from an older ownCloud or fresh install:
Updated from 8.2.2
Where did you install ownCloud from:
Manual upgrade from ownCloud.org
Signing status (ownCloud 9.0 and above):
Integrity checker has been disabled. Integrity cannot be verified.
List of activated apps:
Disabled:
The content of config/config.php:
Are you using external storage, if yes which one: local/smb/sftp/...
Yes - Windows shares as SMB/CIFS
Are you using encryption: yes/no
no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
LDAP
LDAP configuration (delete this part if not used)
Client configuration
Browser:
Chrome: 49.0.2623.87 m (64-bit)
and
Desktop Client Version 2.1.1 (build 5837)
Operating system:
Windows 7 Professional (x64)
Logs
Web server error log
httpd:
nginx:
The text was updated successfully, but these errors were encountered: