rename parent directory and v2 lease breaks

[Steve French]

> did open open bug
> 11178 to track the problem as it can have data integrity implications

typo in above - was bug 11138 not 11178

On Fri, Mar 6, 2015 at 5:34 PM, Steve French <smfrench at gmail.com> wrote:

>
>
> On Fri, Mar 6, 2015 at 4:42 PM, Steve French <smfrench at gmail.com> wrote:
>
>>
>>
>> On Wed, Mar 4, 2015 at 2:08 AM, Ralph Böhme <rb at sernet.de> wrote:
>>
>>> On Wed, Mar 04, 2015 at 06:54:26AM +0100, Volker Lendecke wrote:
>>> > On Tue, Mar 03, 2015 at 02:41:31PM -0600, Steve French wrote:
>>> > > I was testing Samba 4.2 and noticed that renaming the parent
>>> directory
>>> > > did not trigger a v2 lease break for files opened in that directory
>>> > > (it looks like Windows does send one though).
>>> > >
>>> > > Shouldn't rename of the parent directory trigger a lease break for
>>> > > open files in the directory?
>>> >
>>> > Yes, it should.
>>>
>>> Hm, I fail to find this in the doc, the only applicable rule I see is:
>>>
>>> * If Open.File.FileType is DirectoryFile, determine whether Open.File
>>>   contains open files ...
>>>
>>> * If Open.File contains open files, the operation MUST be failed with
>>>   STATUS_ACCESS_DENIED
>>>
>>> in MS-FSA 2.1.5.14.11. The pseudocode algo doesn't mention any lease
>>> break triggering. Am I missing anything? Is this missing in the doc?
>>>
>>>
>> The Microsoft test cases are usually pretty good about referencing which
>> subsection of the document they apply to, but clearly Windows 8.1
>> (as a server, among others) does generate the lease break for the
>> children - otherwise reopen of the file to writeout data after
>> intermittent
>> failure (or any path based op on the file where data integrity of cached
>> data matters) could fail.
>>
>>
>>
> I haven't tried strict rename yet (will see if that helps). but did open
> open
> bug # 11178 to track the problem as it can have data integrity
> implications
>
>
> --
> Thanks,
>
> Steve
>



-- 
Thanks,

Steve