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

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

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 26 Apr 2002 10:04:22 +0200
Cc: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
To: "Clemm, Geoff" <gclemm@rational.com>
Message-Id: <3786235A-58EC-11D6-9959-00039384827E@greenbytes.de>

Am Freitag den, 26. April 2002, um 05:00, schrieb Clemm, Geoff:

> 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> ?

I had a closer look and it's seems to be rather application
specific. What role the frameworks play in this, maybe someone
from apple can elaborate.

The example I gave comes from TextEdit application on OSX.
TextEdit always creates a backup file (test~.txt), but the
default setting is that this backup is deleted. That explains
the strange MOVE/DELETE on that.

I tested with Internet Explorer. IE, if asked to replace an
existing file, will first DELETE the file and then create
a new one.

Then I tested Apple's Mail application. That app will first
create a temp file and then MOVE the temp file to replace
the existing one.

So the answer is: it depends. Which is rather unfortunate.


> 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.
> //Stefan
>> Unless someone comes up with a better idea, I'll add this to the 3253
>> "errata" sheet as an interoperability suggestion for the MOVE request.
>> Cheers,
>> Geoff
>>    From: Kasia Jonca [mailto:Kasia.Jonca@merant.com]
>>    We've been testing Merant versioning WebDAV server with Windows XP
>>    "redirector" and Mac OS X WebDAVFS. The behavior of our versioning
>>    WebDAV server is equivalent to the behavior of the DeltaV server
>>    with auto versioning.  On the surface things seems to be working
>>    but if you look closer the situation is really bad. Both clients
>>    behave like a file system and perform what is called a "safe
>>    save". This means that the new changes are saved in a temporary
>>    file on the WebDAV server, the old file is deleted and then the
>>    temp file is renamed. This means that when a file is being saved we
>>    lose the previous versions, a new version history is created. Both
>>    clients also create a few versions that seem to contain some
>>    temporary values making the version history unacceptably polluted.
>>    We are quite concerned since both Windows XP "redirector" and Mac
>>    OS WebDAVFS would enable access to WebDAV server from any
>>    application on those platforms. With this behavior the only
>>    solution for us or a DeltaV server would be to deny the write
>>    access to these agents so that the user data is not destroyed and
>>    polluted. This is quite a change from our expectations on what
>>    DeltaV would do for us and we are hoping that some solutions can be
>>    still found.  Did anybody test these clients with a DeltaV server
>>    implementation? Any comments, suggestions, explanations?
Received on Friday, 26 April 2002 04:04:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC