|
List Info
Thread: PROPPATCH question (setlastmodified)
|
|
| PROPPATCH question (setlastmodified) |

|
2007-06-10 21:11:31 |
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
AV:">
<D:set>
<D:prop>
<a:getlastmodified>2007-06-09T13-36-32Z</a:getlastm
odified>
</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
|
|
| Re: PROPPATCH question (setlastmodified) |
  Germany |
2007-06-11 02:52:53 |
Tobias Giesen wrote:
> Hello,
>
> I am new to this list and I hope it is OK to raise this
question here.
Absolutely.
> 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
AV:">
> <D:set>
> <D:prop>
>
<a:getlastmodified>2007-06-09T13-36-32Z</a:getlastm
odified>
> </D:prop>
> </D:set>
> </D:propertyupdate>
>
> Can anybody help or tell me where to look or ask for
help?
> Thanks.
Looks ok to me except the namespace prefix on
"getlastmodified", which
should be "D:" here.
> ...
Best regards, Julian
|
|
| Re: PROPPATCH question (setlastmodified) |

|
2007-06-11 14:37:14 |
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
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
|
|
| Re: PROPPATCH question (setlastmodified) |
  United States |
2007-06-11 22:57:19 |
Tobias Giesen wrote on 06/10/07 19:11:
> 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:
I assume that most, if not all servers consider it a
protected property.
>From http://www.greenbytes.de/tech/webda
v/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
|
|
| Re: PROPPATCH question (setlastmodified) |

|
2007-06-12 09:15:24 |
> "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."
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
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
|
|
| Re: PROPPATCH question (setlastmodified) |

|
2007-06-12 10:46:48 |
|
On Jun 12, 2007, at 7:15 AM, Tobias Giesen wrote:
If I can't change the "getlastmodified" attribute, can I store a custom 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 |
[1-6]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|