RE: possible race condition in COPY with overwrite

The issue is not multi-threading, it is atomicity. We need to add an
atomicity requirement to COPY, just as already have done in section 8.9 for
MOVE.

			Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Sunday, November 29, 1998 9:49 AM
> To: w3c-dist-auth@w3.org
> Subject: possible race condition in COPY with overwrite
> 
> 
> Suppose I want to COPY a resource (S) to destination D.  To ensure
> consistency, I take out a lock on destination D.  Since I 
> have locked D, it
> becomes a lock-null resource (per 7.4), and hence it 
> 'exists', so I must
> also specify the Overwrite header (8.8.4) as T, and thus the 
> server MUST
> delete D prior to the copy.  But by 8.10.5,  a successful DELETE of a
> resource MUST cause all of its locks to be removed.  Thus the 
> lock has no
> real protection.  If the server is multithreaded, then while 
> the COPY is in
> progress, as soon as the DELETE finished, a second client could start
> altering D as well.
> 
> The workaround seems to be to lock the parent of D (with 
> depth infinity),
> not D itself.  This causes the newly created resource to 
> inherit the lock
> of the parent (per 7.7)
> 
> Do you agree with this analysis?
> 
> If so, please mention it in "DAV for Dummies" or whatever 
> tutorial document
> is written about WebDAV. I don't think it requires any changes to the
> protocol or the the spec.
> 
> Jim
> 
> 
> ------------------------------------
> http://www.parc.xerox.com/jdavis/
> 650-812-4301
>

Received on Sunday, 29 November 1998 15:46:53 UTC