You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Lisa Dusseault <li...@osafoundation.org> on 2004/11/16 18:26:02 UTC
Behavior of collection copies
Not all servers do the depth-infinity delete during a copy, actually.
For better or for worse, Microsoft servers and I believe Xythos do a
merge of the contents when copying one folder over another. I don't
think it would matter to those servers even if the spec were clearer,
it was a very conscious decision based on customer/user expectations.
Lisa
On Nov 16, 2004, at 5:52 AM, Stefan Lützkendorf wrote:
> Ok, seems I have found the problem.
>
> I fixed an copy issue some time ago.
>
> The following sequence
> mkcol /abc
> put /abc/file1
> mkcol /def
> put /def/file2
> copy /abc -> /def
>
> leads to (before the fix)
> /abc
> /abc/file1
> /def
> /def/file1
> /def/file2
>
> that's wrong, I think, because if the target exists, it is to be
> deleted with Depth: infinity (see RFC2518, 8.8.4).
> but if /def is deleted this way /def/file2 must disappear too
>
> So the correct result is
> /abc
> /abc/file1
> /def
> /def/file1.
>
> This is true for Binding too. But some of the Bind test cases rely on
> the older behavior, I will commit the changes to the testcases soon.
>
> With this functional, deltav and bind are running.
>
> Stefan
>
>
>
> Stefan Lützkendorf wrote:
>
>> Currently some BIND testcases are failing (:-(. I'd like to fix this
>> before releasing again, but I'm currently not quite sure what the
>> problem is. I try ASAP.
>> Stefan
>> Oliver Zeigermann wrote:
>>> Folks,
>>>
>>> after we fixed the Oracle and the Mac OS X blockers are there any
>>> other issues you feel that should be addressed before we can get to
>>> the next release?
>>>
>>> Anyway, should the next release be a beta or a release candidate?
>>> Even
>>> though there have been additional patches, if there are no more major
>>> open issues I would be +1 for a release candidate as 2.1 has been in
>>> the release cycle for quite a while...
>>>
>>> Oliver
>>>
>>> P.S.: James would you be available for a next release soon, anyway?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>
> --
> Stefan Lützkendorf -- luetzkendorf@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Behavior of collection copies
Posted by Stefan Lützkendorf <lu...@apache.org>.
I agree, the depth-infinity delete is more understandable. And if we do
a merge, we have to decide what to do with meta data and file content,
because if I copy a file I expect that the properties are copied too.
So I think with the fix, I described, we have a better solution - close
to the spec and more clear in behavior.
Stefan
Lisa Dusseault wrote:
> Not all servers do the depth-infinity delete during a copy, actually.
> For better or for worse, Microsoft servers and I believe Xythos do a
> merge of the contents when copying one folder over another. I don't
> think it would matter to those servers even if the spec were clearer, it
> was a very conscious decision based on customer/user expectations.
>
> Lisa
>
> On Nov 16, 2004, at 5:52 AM, Stefan Lützkendorf wrote:
>
>> Ok, seems I have found the problem.
>>
>> I fixed an copy issue some time ago.
>>
>> The following sequence
>> mkcol /abc
>> put /abc/file1
>> mkcol /def
>> put /def/file2
>> copy /abc -> /def
>>
>> leads to (before the fix)
>> /abc
>> /abc/file1
>> /def
>> /def/file1
>> /def/file2
>>
>> that's wrong, I think, because if the target exists, it is to be
>> deleted with Depth: infinity (see RFC2518, 8.8.4).
>> but if /def is deleted this way /def/file2 must disappear too
>>
>> So the correct result is
>> /abc
>> /abc/file1
>> /def
>> /def/file1.
>>
>> This is true for Binding too. But some of the Bind test cases rely on
>> the older behavior, I will commit the changes to the testcases soon.
>>
>> With this functional, deltav and bind are running.
>>
>> Stefan
>>
>>
>>
>> Stefan Lützkendorf wrote:
>>
>>> Currently some BIND testcases are failing (:-(. I'd like to fix this
>>> before releasing again, but I'm currently not quite sure what the
>>> problem is. I try ASAP.
>>> Stefan
>>> Oliver Zeigermann wrote:
>>>
>>>> Folks,
>>>>
>>>> after we fixed the Oracle and the Mac OS X blockers are there any
>>>> other issues you feel that should be addressed before we can get to
>>>> the next release?
>>>>
>>>> Anyway, should the next release be a beta or a release candidate? Even
>>>> though there have been additional patches, if there are no more major
>>>> open issues I would be +1 for a release candidate as 2.1 has been in
>>>> the release cycle for quite a while...
>>>>
>>>> Oliver
>>>>
>>>> P.S.: James would you be available for a next release soon, anyway?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>
>> --
>> Stefan Lützkendorf -- luetzkendorf@apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
--
Stefan Lützkendorf -- luetzkendorf@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org