WebDAV issue - rename of directories

[Hamish Rodda]

Hi,

In an attempt to solve http://bugs.kde.org/show_bug.cgi?id=119066 I have found 
the following:

1) Apache 2 in its default configuration does not allow MOVE requests on 
directory objects if the trailing slash is not present in the URL (there is 
an apache configuration workaround but it is not ideal)

2) kio_http's webdav support supports move/rename of URLs. Currently, requests 
for renaming directories come without trailing slashes.  This prompts apache 
2 to respond with a 301 Moved Permanently header.

3) In an attempt to have requests for directory renames come with a trailing 
slash, I added an UDS_URL atom to the stat result for directories.  This is 
successfull in delivering the source URL with a trailing slash to the 
rename() function.

4) The move on the server now succeeds, and KIO and KDirLister are aware of 
the rename.  However konqueror's list view does not get updated.  (Also, 
KDirLister's debug output indicates that the new directory is not stored with 
a trailing slash, so subsequent renames are likely to fail).


I wonder if (3) is really the right approach.  

Alternatives I considered:
a) send the request without the trailing slash, then retry on the moved URL 
inside the ioslave.

b) The best fix (from my POV) would be to convert KIO (or konqueror, if it's 
the culprit) to using trailing slashes when requesting actions on 
directories.  However I realise that this is a rather major change and 
probably would break other ioslaves.

c) find another way to recognise within the slave's rename() function that the 
URLs actually point to directories rather than files. Perhaps we could set 
some metadata on the request?

Thanks for your ideas,

Hamish.

PS. Please cc me, i'm not subscribed currently.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20051229/4a5f0b93/attachment.sig>