Whenever I delete a task in KOrganizer 15.08.3 the DAV Resource is broken afterwards: The status message is: There was a problem with the request. The item has not been deleted from the server. The file or folder the.domain.of.my.server does not exist. (0). When I restart the resource in akonadiconsole a message box pops up with the message "Could not delete ." Otherwise the synchronization works as expected. I can create new entries and modify them. Reproducible: Always
still valid for 15.12.0 release.
I can't reproduce this, it's working fine (tested against ownCloud 8.2.2 with the Tasks application). When this happens is your network up?
i have reproduced this with 15.12.1 and davical server. it is always reproducible. Every single deletion leads to this error. Error message after akonadi restart is is now: "Error while trying to delete calendar item. Error was: No items found" I will create a test account on my server and send you the credentials via mail. Maybe you can reproduce the error with this account.
Thanks Till! I can confirm that this is reproducible on my side with the account you created. I'll update this report after some more testing.
Good news, I found cause of the issue :) Not-so-good news, the resource can't do much about it :( What happens is that KIO HTTP adds a final slash at the end of the URL because when the delete job is created it's impossible to know if the deletion of what is requested is a directory or a file (full picture: it doesn't seem that the argument that would allow the slave to decide if the destination is a file or directory is ever appended in the KIO arguments). I wasn't able to reproduce this with ownCloud because it's not sensitive to this. However Davical seems to be. I'm re-assigning this to KIO to see what can be done. In the meantime you may be able to work around by removing the final slash in the URLs that end with ".ics/" (mod_rewrite FTW!). Also, for me it's OK if you remove the test account.
Looks like a regression caused by 1bdb286f62454bb13cc299abd45a297a56b45cea (the fix for bug 331295). Dawit?
(In reply to David Faure from comment #6) > Looks like a regression caused by 1bdb286f62454bb13cc299abd45a297a56b45cea > (the fix for bug 331295). Dawit? This patch is not / no longer in master that's for sure. And even with it the problem is not really addressed as the final '/' will always be added. The commit 58294ac mentions a fix coming from a discussion on the KDE forums. The original issue was that a 301 response was issued for DELETE requests against directories. AFAICS this is totally normal and the HTTP ioslave should follow the redirect and delete the resource pointed by the Location header, only if the new Location is the same as the previous one with just an extra '/' tacked on at the end. Otherwise just ignore it as it's potentially unsafe. Also it's impossible to know in advance if a URI points to a file or directory because those concepts don't exist unfortunately :(
It looks a bit suspicious to me, that the fix from bug 331295 is referencing KDE 4.12. However, the original issue of this report is reproducible on 15.12,. but not on 4.14. Therefore i doubt, that the concrete commit from bug 331295 is the cause. (Maybe i misunderstood some implications here)
You assume one version number for everything KDE produces ;-) kdelibs is 4.14.x and stays that way. There is no "15.12" version numbering for kdelibs. 15.12 is an Applications release - which is based on kdelibs-4+Qt4 for some apps, and KF5+Qt5 for others.
Don't know if it's 100% related : but not only delete is broken After a migration from 4x series of pim stack which has seems to work, I only understood later than locally recorded event (new, delete and modified) were not pushed to the owncloud server. QURL invalid ("") I backup my data, and delete the ressource and create it fresh. The setup worked, the caldav and carddav collections names and locations are founded, but not synchronisation occur. in console log I can only see Kio jumbo frame 42649 received and on the serveur client interrupt connection.
Also applies to KF5 5.21 and KDEPim from 16.04. This is on Arch Linux and I am getting the exact same issue there for my CalDAV resources.
I have the same problem deleting a task using a davical resource. Creating and changing tasks seems to get properly synchronized. (This is also using KF5 5.21 on openSuSE 42.1)
-> also the mod_rewrite trick did not help me: I do not get a broken state anymore, but whenever i delete an item, the deletion will silently fail on the server side and after this fail there is no more synchronization going on at all.
ok, mod rewrite was my fault. It works with the following rule from Bug 362885 (which is a duplicate of this bug) RewriteEngine On RewriteRule ^(.*\.[iv]cs)/$ $1 [L,PT]
*** Bug 362885 has been marked as a duplicate of this bug. ***
actually, RewriteRule ^(.*\.[iv]c[sf])/$ $1 [L,PT] or RewriteRule ^(.*\.ics)/$ $1 [L,PT] RewriteRule ^(.*\.vcf)/$ $1 [L,PT] would be better, as it is either .ics or .vcf
Hey, I've got the same bug with kdepim 16.04 and it would be great if this could be solved somehow. For now I guess I'll try the rewrite rules.
I have the same problem with my Davical resource. The mod_rewrite rule seems to work. I hope this won't have affect other clients (Android, iOS, etc.). I'm on Fedora 25, KDE Frameworks 5.33, KOrganizer 5.4.3. A fix for this bug is really appreciated!
Still found in Kubuntu 17.10, Korganizer 5.5.3.
Another unhelpful "me too" This bug is still present in: Arch Linux KOrganizer Version 5.7.2 Akonadi Version 5.7.2 kio 5.42.0-1 (kf5) and Davical 1.1.5 on Debian 9 I can confirm that the Rewrite rule for Apache mentioned in Comment 16 solves de problem and does not break CalDav on an iphone client. However I needed to remove and recreate the CalDav resource in Korganizer for things to work.
*** Bug 386136 has been marked as a duplicate of this bug. ***
*** Bug 386047 has been marked as a duplicate of this bug. ***
I can confirm again with more recent versions: frameworks 5.43 and kontact 17.12.3 (5.7.3).
*** Bug 384130 has been marked as a duplicate of this bug. ***
Git commit 7615e3405c3083fe9601423e2c3e767423d7c9a8 by Daniel Vrátil. Committed on 23/09/2018 at 16:17. Pushed by dvratil into branch 'master'. Fix deletion of files from DAV Summary: Don't append slash to the end of what we assume is a directory path as in the case of HTTP we can't always tell for sure if it's a file or a directory. This partially restores change 1bdb286 from Dawit. FIXED-IN: 5.51 Reviewers: dfaure Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D15697 M +2 -6 src/ioslaves/http/http.cpp https://commits.kde.org/kio/7615e3405c3083fe9601423e2c3e767423d7c9a8
Great work, Daniel - works here fine.
(In reply to Wulf from comment #27) > Great work, Daniel - works here fine. ok, this was to soon. now I'm able to delete files; but not directories anymore. as far as I remember, before the patch I was able to delete directories but not files. :-) for me this happens on my own webserver (linux, apache) I don't have and did not have this problem with a webdav-share at Vodafone. weird
webserver access_log with Dolphin (doesn't work): - - [16/Oct/2018:23:33:35 +0200] "PROPFIND /webdav/test6 HTTP/1.1" 301 251 - - [16/Oct/2018:23:33:35 +0200] "PROPFIND /webdav/test6/ HTTP/1.1" 207 1097 - - [16/Oct/2018:23:33:44 +0200] "DELETE /webdav/test6 HTTP/1.1" 301 251 webserver access_log with TotalCommander/Android (works): - - [16/Oct/2018:23:36:07 +0200] "PROPFIND /webdav/test6/ HTTP/1.1" 207 844 - - [16/Oct/2018:23:36:07 +0200] "DELETE /webdav/test6/ HTTP/1.1" 204 -
Gnome (gvfs?) just sends both: "DELETE /webdav/test6" "DELETE /webdav/test6/"
Years later I see the message reported by the OP with a Sogo WebDAV resource added to current KDE Neon (but I see it since at least half a year). Unfortunately, for me the issue appears to break the Akonadi agent which goes offline afterwards. Recreating the agent, deleting the cache etc. does not change anything. Although I know about akonadiconsole, I did not manage to debug the issue. Therefore, I had to stop using the calendar resource with korganizer. I was not able to verify that it related to a deleted task, but it could be.