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: Julian Reschke <julian.reschke@greenbytes.de>
Date: Fri, 26 Apr 2002 09:13:00 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEMEEHAA.julian.reschke@greenbytes.de>
Do XP and OS X really do the same thing`?

1) Regarding Mac OS X, the problem may be caused by the Mac OS File System
Calls that allow "exchanging" file contents [1], which AFAIK is used for
Save operations in traditional Mac applications. Maybe we just need to wait
for the Apple programmers to add limited RFC3253 support to fix this

2) Regarding the XP redirector: well, it's full of bugs anyway, and
Microsoft doesn't seem to consider this an issue.



> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, April 26, 2002 5:01 AM
> To: 'ietf-dav-versioning@w3.org'
> Subject: RE: Problems with Windows XP "redirector" and Mac OS X
> 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.
> //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 03:41:37 UTC

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