Subject: PROPPATCH question (setlastmodified)

From: Tobias Giesen <[email-masked]>
Date: Mon, 11 Jun 2007 04:11:31 +0200

Hello,

I am new to this list and I hope it is OK to raise this question here.

Suppose that a WebDAV server accepts the manipulation of "lastmodified"
timestamps, what would the correct XML be?

I tried the following but I haven't found any server that supports it
yet:

<?xml version="1.0" encoding="utf-8"?>
<D:propertyupdate xmlns:D="DAV:">
   <D:set>
     <D:prop>
       <a:getlastmodified>2007-06-09T13-36-32Z</a:getlastmodified>
     </D:prop>
   </D:set>
</D:propertyupdate>

Can anybody help or tell me where to look or ask for help? 
Thanks.

Kind Regards,
Tobias Giesen

Super Flexible Software Ltd. & Co. KG
Lessingstr. 42
48485 Neuenkirchen, Germany
www.superflexible.com
www.tgtools.com

-----------------------------------------------------------
Registered at register court Steinfurt as HRA 5061
Liability / general partner: TGTools Ltd.
Company No. 05513299
Registered in England and Wales
Directors: Tobias Giesen and Claudia Hübl

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jun 2007 09:52:53 +0200

> I am new to this list and I hope it is OK to raise this question here.

Absolutely.

> Can anybody help or tell me where to look or ask for help? 

Looks ok to me except the namespace prefix on "getlastmodified", which 
should be "D:" here.

> ...

Best regards, Julian

---

From: Tobias Giesen <[email-masked]>
Date: Mon, 11 Jun 2007 21:37:14 +0200

Hello,

many thanks for the replies!

I will investigate this issue further. I am surprised that WebDAV-
related companies know so little about what I call "synchronizing".

People nowadays want to synchronize everything. That means they want
to upload files and have the exact same dates on the server that these
files have on their hard disk. If they upload a file last modified in
2002, then it should say 2002 on the server too.

My company makes and sells Super Flexible File Synchronizer, and
customers want true synchronization including the timestamp. A file
without the original timestamp is not an exact sync and causes lots
of problems.

Kind Regards,
Tobias Giesen

---

From: Joe Feise <[email-masked]>
Date: Mon, 11 Jun 2007 20:57:19 -0700

> I tried the following but I haven't found any server that supports it

I assume that most, if not all servers consider it a protected property.
>From http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html
"15.7 getlastmodified Property
...
Protected:
    SHOULD be protected because some clients may rely on the value for
appropriate caching behavior, or on the value of the Last-Modified header to
which this property is linked."

-Joe

---

From: Tobias Giesen <[email-masked]>
Date: Tue, 12 Jun 2007 16:15:24 +0200

>     SHOULD be protected because some clients may rely on the value 
> for appropriate caching behavior, or on the value of the Last-Modified 
> header to which this property is linked."

Of course this objection could easily be overcome by allowing to change
the attribute only for a file that has just been uploaded. That's all I
want, really.

I heard that there are some servers that support it, at least mod_dav
(you need to modify one line in httpd.conf and restart apache).

My problem is this: synchronization is always bidirectional. In the
first step, my software puts file on the server. When run a second 
time, it sees that the Last Modified timestamps on the server are newer
than the local ones and wants to download the files again, even though
they are not changed.

Of course I have a solution for that, which makes use of a database.
But it would be much better to be able to store the original timestamp
somehow.

If I can't change the "getlastmodified" attribute, can I store a custom
attribute like "mytimestamp"?

Kind Regards,
Tobias Giesen

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 12 Jun 2007 08:46:48 -0700

> attribute like "mytimestamp"?

That may be a better choice if the basic approach works since so many  
servers treat getlastmodified as their own storage timestamp with a  
protected value.

Do you ever have a use case where multiple clients want to sychronize  
the same data, as is commonly done with source code repositories for  
example?  If so, then neither "getlastmodified" or a custom property  
really works.  Where T is the timeline:
  - T: Client A acquires some files locally with timestamp T
  - T+1: Client B synchronizes from the repository
  - T+2: Client A uploads file and sets timestamp T in order to match  
up to local timestamp
  - T+3: Client B relies on ETags for synchronization we hope,  
because otherwise the new file will show up as if it has already been  
synchronized...  even if client B successfully downloads these files,  
do we know that it's capable of setting the local timestamp or will B  
constantly see a mismatch between its local timestamp and the server's?

If every synchronizing client needs a different value timestamp to  
match the time they first acquired the file (downloaded from the  
shared repository or acquired from elsewhere) then you could still  
use custom properties with the username in the property name, but it  
might get pretty unwieldy.

Another option as you point out is a database.  If a full backup/ 
restore system is desired, the clients could each create a "synch  
file" on the server that has the timestamps and other information  
needed to reconstruct the backed up data.

Lisa

---

From: Tobias Giesen <[email-masked]>
Date: Tue, 12 Jun 2007 18:04:09 +0200

> constantly see a mismatch between its local timestamp and the server's?

Personally I don't have a problem with this scenario, as my customers 
use only one client software (mine) and I know that it's capable of
setting the local timestamp. So Client B will know that it needs to
download files even if their timestamp is older than the last time
Client B did a synchronization. It will make its local timestamp
identical and will not constantly see any mismatch.

So, one custom property containing the true last edited/modified
timestamp would be sufficient for me. I will try it and hope that
the WebDAV servers will accept it and actually store it.

Cheers,
Tobias