RE: File creation date, version creation date, and getlastmodified

Lisa Dusseault wrote:

> WebDAV people:  RFC2518 leaves it carefully open whether
> 'getlastmodified' changes when properties of the resource
> change.  It seems useful either way -- users might want to
> get the last time the content was changed, or they might
> want to see the last time the file was touched at all.  Is
> there some precedent?

I seem to recall that moddav does not change the last modified timestamp
when properties are updated.

There has been discussion on this topic previously, with a weak consensus
that the properties should not contribute to last modified changes.  I
think this is the right answer.

Peter Raymond <Peter.Raymond@merant.com> wrote:

> One example of why we keep the "last modified" date separate
> is that our build system uses this to compare with timestamps
> of files on disk to decide if the file is out of date.  If the
> WebDAV client set the last modification time each time a
> property was changed then the build system would think the file
> on disk was "out of date" compared to the file held in version
> control.

I think that this is a common scenario, also found on caching proxies, that
relies upon property updates not being considered a change to the resource.

Clearly there is some ambiguity here.  On the one hand, properties appear
to be 'part of' a resource.  They appear when a resource is created, and
disappear when a resource is deleted.  Operations on a property are via the
URL of the resource.  However, live properties exhibit behaviour that sets
them apart from the resource.  They can change even when a resource is
versioned or locked, and (at least in a couple of implementations) changes
to the resource's properties do not change the last modified timestamp of
the resource.

Lisa Dusseault wrote:

> DeltaV people: What does it mean to get the time file content
> was last "modified", if the file is versioned?  I don't see
> that the behaviour of getlastmodified is specified for a
> Version-Controlled Resource, can this be a recommendation in
> the spec to promote consistency?  For one thing, should
> 'getlastmodified' on the VCR change when it is checked out,
> or when it is checked in, or both?

When a version-controlled resource is checked-out its contents and dead
properties are updated to be the same as the version identified in the
DAV:checked-in property.  Therefore the DAV:getlastmodified timestamp
clearly should be updated to reflect the changes.  Note that the timestamp
value is the server's notion of the time the version-controlled resource
was modified and not the same as the checked-in version's
DAV:getlastmodified.

When a version-controlled resource is checked-in, its content and dead
properties become those of a new version in the version history.  Some live
properties of the version-controlled resource are updated to reflect its
checked-in status.  In this case I argue that the DAV:getlastmodified
timestamp does not change.

Furthermore, if you use UPDATE to update the content and dead properties of
a version-controlled resource to reflect the state of a version in version
history, the DAV:getlastmodified timestamp will be the time that the UPDATE
method was applied and not that of the version.  It it were otherwise
updating the version-controlled resource to an earlier version would make
the last modified time go 'backwards' which would potentially screw up
caching proxies and clients that rely on If-Unmodified-Since: headers etc.

> - time the file was last touched

What is your definition of touched?  Dead property updates?  Given the
number of live / computed properties I assume you agree that their values
do not contribute to the touched timestamp?

Regards,

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

Received on Thursday, 3 May 2001 06:51:41 UTC