WebDAV issues

[rene2000]

Hi,

ich have just tried out TC with the WebDAv plugin. There are two issues.

1) The webDAV plugin seems to break the WebDAV standard by sending an empty PropFind instead of a proper "allprop".

2) I am using the sync functionality in TC to synchronize a WebDAV folder with a local disc. When a file is uploaded to the WebDAV folder during the synchronization process, the proper attribute for the time and date of the file is not set. So the uploaded files always get the current time and date. That is the reason why during the next comparison all uploaded files are suggested for synchronization back to the local drive.

Anything that I did not figure out properly which might solve the above issues?

René

[ghisler(Author)]

1) Not true. RFC2518 (WebDAV) states:

A client may submit a propfind XML element in the body of the request
method describing what information is being requested. It is
possible to request particular property values, all property values,
or a list of the names of the resource's properties. A client may
choose not to submit a request body. An empty PROPFIND request body
MUST be treated as a request for the names and values of all
properties.

2) I have tried that, but none of the WebDAV servers supported it - the time stamp was never set. I even received upload errors with one server, so I removed it.

[rene2000]

1) Not true. RFC2518 (WebDAV) states:

Oh, you are right about that. I have talked to the server developer and they are going to change that.

2) I have tried that, but none of the WebDAV servers supported it - the time stamp was never set. I even received upload errors with one server, so I removed it.

I have talked about this with the server developer as well and we found a vicious circle. RFC 2518 says:

Code: Select all

13.7 getlastmodified Property

   Name:       getlastmodified
   Namespace:  DAV:
   Purpose:    Contains the Last-Modified header returned by a GET
   method without accept headers.
   Description: Note that the last-modified date on a resource may
   reflect changes in any part of the state of the resource, not
   necessarily just a change to the response to the GET method.  For
   example, a change in a property may cause the last-modified date to
   change. The getlastmodified property MUST be defined on any DAV
   compliant resource that returns the Last-Modified header in response
   to a GET.
   Value:      HTTP-date  ; defined in section 3.3.1 of [RFC2068]

The problem now is that changing the getlastmodified is a property change and thus the property getlastmodified must be changed when it is set

We think, this does not make sense. What do you think about this?

René

[ghisler(Author)]

Yes, indeed - the problem is also that the property is called "getlastmodified", which implies that it can only be retrieved, but not be set. It would be SO nice to be able to set it...

[rene2000]

Yes, indeed - the problem is also that the property is called "getlastmodified", which implies that it can only be retrieved, but not be set. It would be SO nice to be able to set it...

I have investigated this a little bit and found out that getlastmodfied cannot be compared with the date of a file. The WebDAV WG has discussed this (at least a little bit). Read yourself at lists dot w3 dot org/Archives/Public/w3c-dist-auth/2000JulSep/0049

René

[ghisler(Author)]

So the conclusion is that "getlastmodified" cannot be set via WebDAV.

[rene2000]

So the conclusion is that "getlastmodified" cannot be set via WebDAV.

Yes. And the suggested solution with etags has the drawback that it tells perfectly if or not the resources are identical. But it fails to tell you what the newer version is. So, synchronization over WebDAv requires both, etag and getlastmodified: First you have to check if resources are identical and if not you can compare getlastmodified with the timestamp of the file.

Another drawback is the fact that there is no strict standard how to calculate the etag. This means, the client has to save all etags which are not available on the client side at the first sync. This leads to the solution that the client has to save etags locally and if those are either not identical compared to the server side etag or a local etag is not available files must be compared using timestamps. This would definitely solve the synchronization issue with different timestamps after upload (etag is available and identical).

Does TC support saving of etags for synchronization? What does "compare by content" do?

René

[ghisler(Author)]

Does TC support saving of etags for synchronization?

No it doesn't. It makes not much sense, because it doesn't help to find newer files. For example, if use A modifies a file, re-uploads it, then user B modifies it and re-uploads it, the two users will have two different etags locally...

[rene2000]

Does TC support saving of etags for synchronization?

No it doesn't. It makes not much sense, because it doesn't help to find newer files. For example, if use A modifies a file, re-uploads it, then user B modifies it and re-uploads it, the two users will have two different etags locally...

This is indeed a use case that does not work with timestamps either because user B will overwrite the changes of user A as the client of user B sees that the local version is newer. In case the client stores etags, it could know that the file has been modified on the server in the meantime (by user A). Indeed, this requires to store and manage etags locally. As I said: etags AND timestamps seems to me the best solution.

René