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

Hi,

I am not sure how your suggestion would help us Geoff.
Let me give a bit more detail on the problem...

Let's imagine you have a VCR at /dav/foo.c, it has a VHR at /dav/vhr/foo1
and a checked-in version /dav/vhr/foo1/v1.

The user connects to this DeltaV server using the Windows XP WebDAV
redirector or MacOS X.
These clients are not DeltaV clients so they don't do an explicit CHECKOUT
but lets imagine 
the server is an auto-versioning server (as ours is):

* The user opens foo.c (the client maybe does a LOCK but basically does a
GET on /dav/foo.c).  

* The user changes the file content and saves...

* So the client does the "safe save" and creates a temporary file so will do
PUT /dav/foo.c.tmp 
  (for example), this will create a new resource (VCR because it is
auto-versioning), 
  a new VHR, version etc.

* The client issues DELETE on /dav/foo.c (we don't delete the VHR and the
version at this point, 
  so /dav/foo1 and /dav/foo1/v1 will still exist and maybe VCRs in other
workspaces will still point 
  to them or maybe they will be dangling).

* The client issues a MOVE to rename /dav/foo.c.tmp to /dav/foo.c.

The net result of this is that EVERY resource on the server has only one
version 
and there are many VHRs and Versions lying around the system some possibly
dangling.
We also noticed that some clients do several PUTs to both the temporary
resource and
the original VCR (resulting in some spurious versions).

I dread to think what would happen with an auto-versioning server with
version controlled
collections...do the clients do the same temporary resource and move trick
with folders?

I understand this is due to the fact that the filesystem redirectors are
being called
by applications which are expecting a filesystem :-) So it's not necessarily
the redirector
which is at fault, the applications are doing this multiple save and move
behaviour and
the redirector is honouring the applications request by doing WebDAV
methods.
But it does seem like a fairly serious problem that will probably be
encountered by and
WebDAV servers being used by these redirector clients.

Any ideas what we can do to protect data from being deleted and from the
proliferation
of unnecessary versions and VCRs in the system?

Our current strategy is to make these clients "read-only" but that seems to
devalue the
usefulness of having filesystem redirectors.

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com



-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 24 April 2002 13:49
To: 'ietf-dav-versioning@w3.org'
Subject: RE: Problems with Windows XP "redirector" and Mac OS X
WebDAVFS.


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.

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?