W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2002

Re: Antwort: RE: Problems with Windows XP "redirector" and Mac OS X WebDAVFS.

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 26 Apr 2002 13:46:36 +0200
Cc: ietf-dav-versioning@w3.org
To: "Edgar Schwarz" <Edgar.Schwarz@marconi.com>
Message-Id: <439EA4F3-590B-11D6-9959-00039384827E@greenbytes.de>

Am Freitag den, 26. April 2002, um 13:06, schrieb Edgar Schwarz:
> Hi Stefan,
> why are you so pessimistic ?
> I would assume that most "safe save" algorithms will have a 
> recognizable
> pattern
> like MOVE a -> b, PUT a, DELETE b.

this sequence of operations has an outcome which is defined
by the RFCs 2518 and 3253. That definition makes sense if a
client wants to safely replace a *without* autoversioning.

A client which wants to do autversioning should do
PUT b, COPY b -> a, DELETE b.

> So a clever autoversioning server could assume that b was a 
> temporary file
> which
> can be thrown away (Also deleting the autoversioned history) and
> autoversion a.

The problems with this are:
- the servers is guessing on the intention of the client - this
   could be wrong
- Only after DELETE b, the server could guess that the new a is the next
   version of the former a (now b).
- Before DELETE b, the new a is either a unversioned resource or a
   VCR with its own, new version history.
- The situation gets easily messy if someone does a PROPPATCH a
   before DELETE b. If a is a VCR at that time, autoversioning strikes
   again and a has 2 versions. Both versions need to be applied
   to the version history of the "old" a...
- How long should a server monitor for a DELETE after the PUT a?

> Or is this assuming too much and the behaviour can also be 
> expected in the
> wild by a DeltaV client ?

> Mit freundlichen Grüßen / Best regards
> Edgar Schwarz
> --
> Edgar.Schwarz@marconi.com, Postf. 1920, D-71509 Backnang,+49 7191 
> 13 3382,
> Marconi Communications, Access Division, Quality and Process 
> Improvement
> Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag
> (Niklaus Wirth). Make it as simple as possible, but not simpler
> (A.Einstein)
>                           "Clemm, Geoff"
>                           <gclemm@rational.c        An:    
> "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
>                           om>                       Kopie:
>                           Gesendet von:             Blindkopie:
>                           ietf-dav-versionin        Thema: RE: 
> Problems with Windows XP "redirector" and Mac OS X WebDAVFS.
>                           g-request@w3.org
>                           26.04.2002 05:00
> If the client first does a MOVE, then I agree there's not
> much an auto-versioning server could reasonably do.
> Just for interests sake, what is the motivation for
> those libraries to do a <MOVE-to-temp1, PUT-to-temp2,
> MOVE-to-real, DELETE-temp1> instead of the simpler
> <PUT-to-temp, MOVE-temp-to-actual> ?
> Cheers,
> Geoff
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Am Mittwoch den, 24. April 2002, um 14:49, schrieb Clemm, Geoff:
>> One workaround that comes to mind is to interpret a MOVE from a
>> non-version-controlled resource to a checked-out VCR as a COPY/DELETE.
> First the good news: if you have a shell on OSX and do a
> cp test.txt to /Volumes/dav/test.txt
> where "dav" is a WebDAV mounted volumes, the webdav code
> in OSX does basically a LOCK/PUT/UNLOCK on an existing
> test.txt. So (auto)versioning will do the job.
> However if you use the Finder or any Carbon/Cocoa Application,
> some library code will do (on save in the GUI):
> 1) MOVE /Volumes/dav/test.txt /Volumes/dav/test~.txt
> 2) PUT  /Volumes/dav/data1234.txt
> 3) MOVE /Volumes/dav/data1234.txt /Volumes/dav/test.txt
> 4) DELETE /Volumes/dav/test~.txt
> (modulo LOCK/UNLOCK)
> I see no chance to keep any versioning on text.txt.
Received on Friday, 26 April 2002 07:46:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT